• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 974 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Reliable Flash Writes - CC2541

Ed Hepler
Expert 1940 points

I'm using HalFlashWrite to write data into a buffer.   The timing is such that a couple of words are written every millisecond.  The loop looks something like:

while(sensorDataAvailable >= 8) {     // See if at least 8 bytes are available

  getSensorData8(&dataBuffer);          // Get 8 bytes of sensor data

  HalFlashWrite(flashAddr, (uint8 *)&dataBuffer,(uint16)2);   // Write two 32-bit words to flash

  sensorDataAvailable = sensorDataAvailable - 8;

  flashAddr = flashAddr + 2;

  flashCnt = flashCnt + 8;

}

I have noticed that often the data I read back is 0xffffffff, indicating that the writes might not be happening...

I put the function calls "hal_LED_On()" before the HalFlashWrite and "hal_LED_Off()" after HalFlashWrite and the data being read back is what I expect!

These calls simply turn an LED on and off, but add some delay.

I find it hard to believe that this is making the writes work...   But when I take them back out, the inconsistencies return.

Is there something else that I need to do to use HalFlashWrite successfully?

I looked at the HalFlashWrite code and see that it uses DMA channel 0.   Does anything else (BLE, etc.) use this channel?

Should interrupts be disabled around flash writes?

Thanks!

  • 0
    Mastermind 8695 points
    Post the code you use to read the data back
  • 0 in reply to Peter Borenstein
    Expert 1940 points
    I'm filling a data structure that becomes the payload for a notification. The data structure holds a sequence number (2 bytes) and an array of sensor data (18 bytes). The code to read is pretty straightforward, and looks something like:

    while(flashByteCnt >= 18) {
    ... // Prepare notification

    // Read Flash
    flashPage= (uint8)((flashRead32Addr >> 11) & 0x7f);
    flashOffset= (uint16)(flashRead32Addr & 0x7ff);
    HalFlashRead(flashPage, flashOffset, (unsigned char *)&(notification_value_area),18);
    flashByteCnt= flashByteCnt - 18;
    flashRead32Addr= flashRead32Addr + 18;
    // Send notification
    ...
    }
  • 0 in reply to Ed Hepler
    Mastermind 8695 points

    It looks good at a glance. I would check that flashAddr is the word address (actual/4).  I can't tell based on your first post

    HalflashWrite already has a wait "while (FCTL & 0x80);". I think this only waits for the first word to be written, but its been a while since I've looked at it.

    You can set a break point in HalFlashRead() and check the upper 32KB of XDATA for your data after MEMCTR has been set. The write operation is harder to debug since the DMA is doing everything instead of the CPU.

  • 0 in reply to Peter Borenstein
    Expert 1940 points
    I think the addresses and reads are OK, as everything seems to work when the "LED" on/off statements are there. Things get unreliable when they are taken out (and this is the only change made when recompiling!). So I figured something was happening w.r.t. timing around the Flash writes... I know BLE uses the flash and the DMA. Is there any chance that BLE takes an interrupt and somehow interferes with this??

    Thanks!