ARMmbed / lorawan-fota-demo

Superseded by https://github.com/armmbed/mbed-os-example-lorawan-fuota
Other
16 stars 12 forks source link

On Chip Debug #3

Open wparkermackenzie opened 6 years ago

wparkermackenzie commented 6 years ago

Hello, What is your strategy for on chip debugging with the LTEK FF1705? The build fails when I specify the debug profile. Thank you in advance, Parker

janjongboom commented 6 years ago
  1. Disable the bootloader in mbed_app.json.
  2. Build with the debug profile in /profiles. You cannot use the normal Mbed OS build profiles as they are too big.

    $ mbed compile --profile=./profiles/debug.json

After this you can link the application with debug spec.

wparkermackenzie commented 6 years ago

Thank you, that was the clue I needed. Unfortunately, when running in this way, the application does not get very far as there seems to be a problem with the timers. On the terminal is an indication of a Timer error after attempting to initialize the radio, while the application spins in mbed_die() blinking whats seems to be SOS on the main LED. I am digging in; however, any thoughts or suggestions would be most welcome.

From the terminal

Hello from application version 27
[INFO] Initialize radio...
Timer 0x20004888 error -3: Resource not available

GDB backtrace:

^C
Program received signal SIGINT, Interrupt.
0x08010950 in wait_us (us=150000) at ./mbed-os/platform/mbed_wait_api_rtos.cpp:43
43      while ((us_ticker_read() - start) < (uint32_t)us);
(gdb) bt
#0  0x08010950 in wait_us (us=150000) at ./mbed-os/platform/mbed_wait_api_rtos.cpp:43
#1  0x080108f6 in wait_ms (ms=150) at ./mbed-os/platform/mbed_wait_api_rtos.cpp:31
#2  0x0800fb2e in mbed_die () at ./mbed-os/platform/mbed_board.c:40
#3  0x08010598 in _exit (return_code=1) at ./mbed-os/platform/mbed_retarget.cpp:778
#4  0x080105bc in __wrap_exit (return_code=1) at ./mbed-os/platform/mbed_retarget.cpp:829
#5  0x0800fde6 in error (format=0x8033bdc "Timer %p error %i: %s\r\n") at ./mbed-os/platform/mbed_error.c:42
#6  0x08011042 in EvrRtxTimerError (timer_id=0x20004888, status=-3) at ./mbed-os/rtos/TARGET_CORTEX/mbed_rtx_handlers.c:114
#7  0x0801527a in svcRtxTimerStop (timer_id=0x20004888) at ./mbed-os/rtos/TARGET_CORTEX/rtx5/rtx_timer.c:281
#8  0x08011134 in SVC_Handler ()

Procedure

Breakpoint 1, main () at ./src/main.cpp:329 329 printf("Hello from application version %d\n", APP_VERSION); (gdb) list 324 void blink() { 325 led = !led; 326 } 327 328 int main() { 329 printf("Hello from application version %d\n", APP_VERSION); (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x08010952 in wait_us (us=400000) at ./mbed-os/platform/mbed_wait_api_rtos.cpp:43 43 while ((us_ticker_read() - start) < (uint32_t)us); (gdb) bt

0 0x08010952 in wait_us (us=400000) at ./mbed-os/platform/mbed_wait_api_rtos.cpp:43

1 0x080108f6 in wait_ms (ms=400) at ./mbed-os/platform/mbed_wait_api_rtos.cpp:31

2 0x0800fb52 in mbed_die () at ./mbed-os/platform/mbed_board.c:45

3 0x08010598 in _exit (return_code=1) at ./mbed-os/platform/mbed_retarget.cpp:778

4 0x080105bc in __wrap_exit (return_code=1) at ./mbed-os/platform/mbed_retarget.cpp:829

5 0x0800fde6 in error (format=0x8033bdc "Timer %p error %i: %s\r\n") at ./mbed-os/platform/mbed_error.c:42

6 0x08011042 in EvrRtxTimerError (timer_id=0x20004888, status=-3) at ./mbed-os/rtos/TARGET_CORTEX/mbed_rtx_handlers.c:114

7 0x0801527a in svcRtxTimerStop (timer_id=0x20004888) at ./mbed-os/rtos/TARGET_CORTEX/rtx5/rtx_timer.c:281

8 0x08011134 in SVC_Handler ()

janjongboom commented 6 years ago

So I think we're running out of memory in debug configuration and that's why not all peripherals can be initialized... Maybe upping stack size on the main thread works but we're already pretty memory limited. I could have some time later this week to examine.

wparkermackenzie commented 6 years ago

The code stops functioning with the call to lora::Mote::Mote(lora::Settings*, lora::ChannelPlan*) in the object library provided by Multitech with the US915 channel plan; someplace after the 2nd call to new. The last call to the malloc wrapper observed the memory utilization to be as follows: {current_size = 9266, max_size = 9266, total_size = 9266, reserved_size = 0, alloc_cnt = 10, alloc_fail_cnt = 0}

However, while in the panic mbed_die the heap_stats are observed to be reset back to 0. {current_size = 0, max_size = 0, total_size = 0, reserved_size = 0, alloc_cnt = 0, alloc_fail_cnt = 0}