Other Parts Discussed in Thread: SYSBIOS
Tool/software: TI-RTOS
CC2640 custom 4x4 application. CCS 6.2, ble_sdk_2_02_01_18, XDS 200 debugger. Application uses the SPI (master), UART (wired external processor communication only during sensor calibration) and ADC drivers (ADC driver used only if an external sensor is present, not used otherwise).
After calibration, there is a power cycle and the sensor operates in normal mode without opening the uart driver.
The exact length of the incoming UART message frame is unknown. The time between the UART message frames is also not known. Each message frame has a start of header byte followed by a message frame identification byte. There is no other handshaking method used for the CC2640 to communicate with the external processor.
Current use of UART driver: Read callback, write blocking mode.
Application sequence:
1. If there is activity on uart receive pin, only then open the UART driver.
2. If the UART driver is opened, start waiting for an uart byte to arrive. UART is always read one byte at a time.
3. If the uart read callback triggers, put the uart event in the RTOS queue. Currently, an enqueue function is being used in the swi context (triggered by the uart read callback).
4. The incoming message frame is assembled in the RTOS queue. Upon assembling the message, the uart also writes from the RTOS queue. After the uart write, the CC2640 goes back to waiting for an incoming uart message until calibration is complete.
5. Max time out between 2 consecutive incoming bytes is set to 1900 clock ticks (10 us per clock tick) upon which the incoming frame is discarded.
Using the UART in read callback mode involves ongoing reading the UART driver except when there is data to write from the UART driver. The UART read indicates a status error of -1, occassionally this changes to a 0.
A hard fault error is reported after the upgrade to ble_sdk_2_02_01_18 when the sensor talks through the uart. The memory location of the hard fault (BFAR) leads to an unknown memory location. Setting an ARM advanced feature halted the debugger at the hard fault, but ROV did not update with the exception report and information needed to understand the problem further. This error seems to be masked by the presence of debug statements (hard fault exception does not happen).
Some inconsistencies were also noted when talking through the UART using ble_sdk_2_02_00_31. This seemed to go away when the response to a specific uart message was changed. All was well otherwise.
Upon project review from one TI engineer, one of the suggestions was to add an uart task and read the uart in blocking mode.
The UART task is created only in the presence of UART pin activity, not otherwise.
Uart task priority = 2
SBP task priority = 1
A semaphore was set up to alert the SBP task that the UART is done writing so the SBP task can take over at the end of a UART message.
This set up is breaking the BLE advertising. The sensor is hitting the hard fault exception whether or not UART activity is present. GAP role task ends up being blocked and an unknown task with 0 stack size is shown in the ROV. (Two screenshots attached).
Is it a better design to use a UART task versus continuous reading of the UART? How to set up the UART task if this is a better way to design the firmware?
Or is this a non-issue with the UART driver setup and monitoring and all will be well with the CC2640R2 chip and stack? Please advise.
Thanks,
Priya
