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/LAUNCHXL-CC2650: Strange behavior with OADTarget_readFlash function

Part Number: LAUNCHXL-CC2650

Tool/software: TI-RTOS

If I define and initialize sectorbytes as:

uint8_t sectorbytes[4096] = {0};

Then in a buttonpresshandler function I have this code:

  switch (pState->pinId)
  {
    case Board_BUTTON0:
      if (pState->state) // Only do once per button press
      {
          if (OADTarget_open())
           {
              OADTarget_eraseFlash(1);
              OADTarget_readFlash(1, 0, sectorbytes, 4096);
           }
           OADTarget_close();
           Log_info1("%s", (IArg)"Erase and Read of sector 1");
      }
      ButtonService_SetParameter(BS_BUTTON0_ID,
                                 sizeof(pState->state),
                                 &pState->state);
      break;

...

If I size sectorbytes as 3073 or greater, when the button is pressed, sectorbytes is set to 3072 0x00's and the rest 0xFF's

If I size sectorbytes as 3072 or less the resulting sectorbytes is all 0xFF's

My understanding of the MX25R8035F flash and of OADTarget_eraseFlash is that it erases one whole 4k sector at a time, so any read of an erased sector up to 4096 bytes should return all 0xFF's.

What is happening here or is there a better forum for this?

Thanks,

Dale

  • To further isolate this issue I did this:

    I define and initialize:

    uint8_t sector1start[12] = {'S', 'e', 'c', 't', 'o', 'r', '1', 's', 't', 'a', 'r', 't'};
    uint8_t sectorbytes[4096] = {0};

    Then, in a buttonpresshandler function I have this code:

      switch (pState->pinId)
      {
        case Board_BUTTON0:
          if (pState->state) // Only do once per button press
          {
              if (OADTarget_open())
               {
                  OADTarget_eraseFlash(1);
                  OADTarget_writeFlash(1, 0, sector1start, 12);
                  OADTarget_readFlash(1, 0, sectorbytes, 4096);
               }
               OADTarget_close();
               Log_info1("%s", (IArg)"Erase, Write and Read of sector 1");
          }
          ButtonService_SetParameter(BS_BUTTON0_ID,
                                     sizeof(pState->state),
                                     &pState->state);
          break;

    .....

    When I run that, I find out that sectorbytes has the 12 character string "Sector1start" in it, but its location is at 3072. This says more that the issue is that the read function is not starting at the correct address in memory.

    Can anyone else confirm my findings or is there something wrong with my setup?

    EDIT: If I read the flash anywhere, but only read 256 bytes at a time, I can see that the original write operated correctly and the problem is with a longer read reporting different data than the short read.

    Thanks,

    Dale

  • You are right, you can only write 256 bytes at a time to this flash. Did you check if ExtFlash_write() returns false if the more than 256 bytes are attempted written?

  • I understand the page programming, I have not written anything bigger that 256 bytes.

    The problem is that a long read does not return the correct data.

    Dale
  • You can also only read 256 bytes at a time. Looking at the implementation of ExtFlash_read() and ExtFlash_write() it appears that writing more than 256 bytes would work. Each 256 byte access is enclosed in a loop whereas no such loop exists in the read function.
  • Yes, but the data sheet MX25R8035F does not limit how much data can be read at a time and as you say the read function does not limit it either.

    Where in the ExtFlash_read() does it limit to a 256 byte read?

    So, why does a long read gives us wrong data?

    Dale

  • Flash read uses SPI driver which has limitation on how much it can transfer at a time. You can take a look at SPICC26XXDMA.c
  • Hi Christin,

    Sorry, I am not able to see where the SPI driver limits reads to 256 bytes in SPICC26XXDMA.c.

    In any case, as long as I limit myself to 256 byte reads, all is well and I will make the assumption that there is no lurking issue that will bite me unless I go bigger.

    Dale