This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE_NUS Service + FATFS storage on external flash

Hello, guys!

We are using nRF52840 SoC together with the 15.3.0 version of SDK.

In our project, we basically want to combine BLE_NUS services together with the ability to store data on external QSPI flash formatted in FATFS. 

The set of desired activities would be as follows:

1. Send an Initial data package over BLE_NUS

2. Once the first data packet is detected, create a new file with open_apend() function.

3. Receive the rest of the BLE_NUS packets and append them in the previously created file.

4. Receive the last data package, store it in the file, and close the file.

Now, we are able to perform the steps only separately. We can send the data over BLE_NUS, we can create, open, delete, and list the files on the external flash. The trouble comes when we want to combine things.

Namely, If I try to create a file with open_apend() function (or simply to list the files in the flash with fatfs_ls() function) from within nus_data_handler() function, the program simply freeze and nothing happens.

Do you have any idea why that might happen?

Thanks in advance for your time and efforts.

Sincerely,

Bojan.

Parents
  • Hello Bojan,

    I guess this relates to interrupt priorities. The nus_data_handler() is inside the Softdevice 'SD_EVT_IRQn' interrupt context with priority 6 which is the same as the default priority used by all of our peripheral drivers. In other words, I think it's likely that your QSPI driver interrupts are getting blocked by the SD interrupt handler in this case.

    You could try to increase the interrupt priority of the QSPI driver and see if it helps. However, it's generally considered good practice to avoid blocking calls inside interrupt handlers so I would instead suggest to deffer processing of these calls to the main context. One way you can do that is by setting a volatile flag inside the nus handler and do the processing from your main loop.

    Something like this:

    static volatile bool m_received_first_packet;
    void nus_data_hanlder(..)
    {
        ...
        if (<first data packet received>)
        {
            m_received_first_packet = true;
        }
        ..
        
    }
    
    int main(void)
    {
        ...
        for(;;)
        {
            if (m_received_first_packet)
            {
                m_received_first_packet = false;
                open_apend();

    Best regards,

    Vidar

Reply
  • Hello Bojan,

    I guess this relates to interrupt priorities. The nus_data_handler() is inside the Softdevice 'SD_EVT_IRQn' interrupt context with priority 6 which is the same as the default priority used by all of our peripheral drivers. In other words, I think it's likely that your QSPI driver interrupts are getting blocked by the SD interrupt handler in this case.

    You could try to increase the interrupt priority of the QSPI driver and see if it helps. However, it's generally considered good practice to avoid blocking calls inside interrupt handlers so I would instead suggest to deffer processing of these calls to the main context. One way you can do that is by setting a volatile flag inside the nus handler and do the processing from your main loop.

    Something like this:

    static volatile bool m_received_first_packet;
    void nus_data_hanlder(..)
    {
        ...
        if (<first data packet received>)
        {
            m_received_first_packet = true;
        }
        ..
        
    }
    
    int main(void)
    {
        ...
        for(;;)
        {
            if (m_received_first_packet)
            {
                m_received_first_packet = false;
                open_apend();

    Best regards,

    Vidar

Children
Related