UART and FreeRTOS

RE: UART and FreeRTOS

Susheel Nuguru — Mon, 28 Jan 2019 09:18:51 GMT

Hi dmleone,

I think first you should hold on your code and try to understand its internals. I think what you are facing is the problem understanding the code structure and since you are new to FreeRTOS, you have problems understanding the statemachine of your application.

[quote user="dmleone"]Also they used SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk, however i am having difficulty finding exactly what that is doing or how it works[/quote]

This is ARM Cortex M4 system control block feature of deep sleep.

[quote user="dmleone"]Is there a better way to handle a sleep mode where i can wake it up with the UART? [/quote]

If the choice of your system was to make the nRF chip to go to systemoff (not the same as ARM cortext sleep mode), then you need a mechanism to wake it up and waking from GPIO pins sounds reasonable. But if you do not want to go to deepsleep (System off) then using WFE will wake the system on any internal events.

I would not be able to suggest you which mode to use, as it entirely depends on your product requirements.

[quote user="dmleone"]Is there a way other than using an input with nrf_gpio_cfg_sense_input() to wake up the system? The system is able to receive a BLE incoming message during this sleep mode and before putting it to sleep they call sd_ble_gap_disconnect(). I am assuming in the code somewhere they have to wake or do something to be able to reconnect with the device before the device sends a message, otherwise it would never get the message. I am looking for this wakeup on BLE action[/quote]

When the system wakes up from systemoff (deep sleep) there will be a system reset and if your application is not checking for the reset reason, then the statemachine would always have the same path on the wakeup. This means that your device will again try to attempt to connect as it did before going to sleep.

RE: UART and FreeRTOS

dmleone — Fri, 25 Jan 2019 20:12:45 GMT

Just to give a heads up it may seem like i do not know what is happening because i am working on someone elses code and there is no reference and i have never used freeRTOS or nRF52 before. So if there is something that you may think is trivial it may not be for me. I can upload files to you. but prefer a more direct method or secure method than posting all over the internet

I stripped my program down to the bare bones UART only task and got it working. I put all the same code back in and it still worked. so i am kinda of ok but i got another issue

After 1 minute, the system no longer responds. I saw another post that exhibited same issue was wondering if you knew why this was happening for him and may lead me to know why it is happening to me

Older Post no resolution

if I do the only UART task it seems to last longer than 1 minute. but with the BLE enabled it dies after 1 minute. I am trying to search through all the code to determine if there is some BLE timeout since that is what i gather from the older post i linked to.

Also they used SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk, however i am having difficulty finding exactly what that is doing or how it works

Edit: Reviewed the code and it appears i may have same issue as older post. The system boots up and after allotted time, 1 minute, it calls sd_power_system_off(). This causes whole system to go into a stop mode until we hit a button to wake it up.

Is there a better way to handle a sleep mode where i can wake it up with the UART?

Is there a way other than using an input with nrf_gpio_cfg_sense_input() to wake up the system? The system is able to receive a BLE incoming message during this sleep mode and before putting it to sleep they call sd_ble_gap_disconnect(). I am assuming in the code somewhere they have to wake or do something to be able to reconnect with the device before the device sends a message, otherwise it would never get the message. I am looking for this wakeup on BLE action

RE: UART and FreeRTOS

Susheel Nuguru — Fri, 25 Jan 2019 09:12:33 GMT

I believe that something is not correctly configured with your uart. If you configured to use FIFO then you will get AA_UART_DATA and not APP_UART_DATA_READY. The driver itself is working in interrupt driven mode, so that should be OK, any data received should have called

uart_evt_callback-> tb_uart_send_event(you need to put this all in APP_UART_DATA case and not in APP_UART_DATA_READY if you use fifo) ->xQueueSendToBack-> handle_uart_evt

I do not see any other complications in this path

RE: UART and FreeRTOS

Susheel Nuguru — Fri, 25 Jan 2019 09:04:59 GMT

I am pretty sure that there is not much differences in the way you handle tasks in our port. It must be something with the tasks. Can you give me a compilable file/project to test this out on my end?

I see no obvious issues in your code, and even tried to compile falling into the loop of fixing compilation error. It would be easy to give me a file to test and not spend too much time fixing compiler errors.