Why do I get an exception reading second half of K70 flash?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Why do I get an exception reading second half of K70 flash?

580 Views
MikeJones
Contributor III

I am trying to use the flash driver using code that worked with MQX 3.8 on a K60, but using MQX 4.0 on a K70 (standard Tower K70F120 board).

I have defined:

#define BSPCFG_ENABLE_FLASHX                      1

#define BSPCFG_FLASHX_SIZE                        0x100000

Which is the size of memory as described in the reference manual.

I open the driver as such:

    fdStore = fopen(FLASH_LOGGER_STORE_NAME, NULL);

  if (fdStore == NULL) {

  printf("\nUnable to open file %s\n", FLASH_LOGGER_STORE_NAME);

  _msg_free(msg_ptr);

  continue;

  }

  ioctl(fdStore, FLASH_IOCTL_ENABLE_SECTOR_CACHE, NULL);

  len = read(fdStore, &initialized, sizeof(initialized));

If I step through the read function, it eventually gets to a memcpy that produces a fault. If I try to read from memory in the last 32K of the 1MB space, I get the fault. I am absolutely certain I am within the BSPCFG_FLASHX_SIZE and that the destination address is good.

I tried an experiment by changing the code to read/write in the last 32K of Bank 0, which is just under the 512K mark. I did not get the fault on the first read access. The code then did a write followed by a read, the data read back did not match. To read the data after writing I do:

  fseek(fdStore, 0, IO_SEEK_SET);


The first data came back all 0xFF followed by some random value for the next two 32 bit values, but the second and third values were the same.

If I rerun the program I then get the fault. A power cycle does not fix the problem. I can run it 100 times and fault in exactly the same place in the code as the original fault at the end of Bank 1.


It behaves as if after the memory is read/write/read once you can no longer read it without a fault.

To be double sure, I grabbed a second board and tried again.

With this board the read still returned the wrong data on the first try, but the second try did not produce an exception.

So I looked a bit closer at the code:

    fdStore = fopen(FLASH_LOGGER_STORE_NAME, NULL);

  if (fdStore == NULL) {

  printf("\nUnable to open file %s\n", FLASH_LOGGER_STORE_NAME);

  _msg_free(msg_ptr);

  continue;

  }

  ioctl(fdStore, FLASH_IOCTL_ENABLE_SECTOR_CACHE, NULL);

  store_size = (FAULT_LOG_SIZE-sizeof(initialized)-sizeof(first_position)-sizeof(next_position)) / sizeof(NVM_LOGGER_ENTRY_STRUCT);

  // store_size = store_size / 4;

  len = read(fdStore, &initialized, sizeof(initialized));

  // Initialize NVM if not used

  if (initialized != FLASH_LOGGER_INITIALIZED_SIGNATURE)

  {

  fseek(fdStore, 0, IO_SEEK_SET);

  initialized = FLASH_LOGGER_INITIALIZED_SIGNATURE;

  len = write(fdStore, &initialized, sizeof(initialized));

  first_position = 0;

  len = write(fdStore, &first_position, sizeof(first_position));

  next_position = 0;

  len = write(fdStore, &next_position, sizeof(next_position));

  fflush(fdStore);

  }

  // Get the positions of where data begins and ends

  fseek(fdStore, 0, IO_SEEK_SET);

  len = read(fdStore, &initialized, sizeof(initialized));

  len = read(fdStore, &first_position, sizeof(first_position));

  len = read(fdStore, &next_position, sizeof(next_position));

The read that fails are the last three lines. They don't return the correct values, but after restarting the program, it does. So that seems to indicate the flush() call no longer guarantees read/write integrity. If should have read/write integrity without it, I just use it to force the data to flash in case power is lost.

So I guess this is a second question, why I don't read back what was written? Do I have to close the flash driver first?

To be complete, I went back to the first board, and it produces the exception.

So either the board don't behave the same, or one is damaged.

Any ideas?

More info on 12/03/13

Now a second board is behaving the same way. I have attached a screen shot. If I step the debugger, I end up with an exception. Also attached.

Message was edited by: Mike Jones

Labels (1)
0 Kudos
Reply
0 Replies