This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/TIDC-BLE-TO-WIFI-IOT-GATEWAY: Device stopping suddenly

Prodigy 70 points

Replies: 2

Views: 378

Part Number: TIDC-BLE-TO-WIFI-IOT-GATEWAY

Tool/software: TI-RTOS

Hi All,

I have modified the BLE to WiFi Gateway reference design to continuously scan for Bluetooth devices and publish their scan responses over MQTT without any filtering of the data. This means that I am picking up data of every Bluetooth device in the proximity and hence the load on the device is a lot. The device is stopping and I am getting the following messages in the console:

ti.sysbios.family.arm.m3.Hwi: line 1036: E_hardFault: FORCED
ti.sysbios.family.arm.m3.Hwi: line 1113: E_busFault: PRECISERR: Immediate Bus Fault, exact addr known, address: 20040000
Exception occurred in background thread at PC = 0x2001f380.
Core 0: Exception occurred in ThreadType_Task.
Task name: {unknown-instance-name}, handle: 0x2002e5e0.
Task stack base: 0x65800e2b.
Task stack size: 0x62e9c21d.
R0 = 0x20031d58  R8  = 0x2002d328
R1 = 0x2003fff4  R9  = 0x00000000
R2 = 0x200288c0  R10 = 0x2003c00a
R3 = 0xfd148350  R11 = 0x00000000
R4 = 0xe68eba9d  R12 = 0x2002d338
R5 = 0x4b96596f  SP(R13) = 0x2002ee30
R6 = 0xe59450be  LR(R14) = 0x2001f765
R7 = 0x00000020  PC(R15) = 0x2001f380
PSR = 0x21000200
ICSR = 0x0440f803
MMFSR = 0x00
BFSR = 0x82
UFSR = 0x0000
HFSR = 0x40000000
DFSR = 0x0000000a
MMAR = 0x20040000
BFAR = 0x20040000
AFSR = 0x00000000
Terminating execution...

The following is a screenshot of the debug window:

I need help in figuring out what is the reason behind the device stopping like that. I understand that the specific reason will depend on all the modifications that I have done, but a generic explanation can help me pin-point the cause on my end.

Best regards,

Arpit

2 Replies

  • Hey Arpit,

    Were you able to determine where it crashes? Place breakpoints throughout your application to identify where failure occurs first.

    BR,
    Seong
  • In reply to Seong Kim:

    Hi Seong,

    Thanks for the reply. The issue with the BLE to WiFi gateway is that if I do put any breakpoints, the BLE and WiFi MCUs go out of sync. This leads to the WiFi MCU waiting indefinitely for the "GAP_DEVICE_DISCOVERY_EVENT" occur and gets stuck in loop. This makes debugging using breakpoints nearly impossible. However, with regards to my query, I had a similar issue before where the interrupt stack was overflowing. This had happened because I was posting too many messages in the Gateway event and data queues.

    I am printing many messages through the UART to a terminal to see where the device is stopping and have not found any particular place where the failure occurs first. The failure is random and I have not been able to find a correlation between the time for which the device has been running, number of other Bluetooth devices in the proximity, connectivity to WiFi, connectivity to MQTT broker, number of messages sent over MQTT, length of data from other Bluetooth devices, and the configuration of the Bluetooth MCU w.r.t. scan duration and maximum number of device responses.

    It would be very helpful if I can get some insight into the working of the RTOS and understand if any particular situation(like too many interrupts) can cause the failure of the device in this manner.

    Best regards,

    Arpit

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.