RTCS kills Flash!!

[michaelschwager]

Hi, I'm using MQX 4.1.1 and both K60DN512ZCAB1 and K60DN512VLQ10 with a custom PCB.

I've found that calling RTCS_create(...) prevents my application from using FlashX. :smileysad:

Very sad, yes, I know.

Prior to this I could use this to do firmware updates and store calibration parameters.

Now with RTCS enabled, any attempts to write to Flash fail!!

Specifically when it goes to flash_ftfl.c->ftfl_flash_command_sequence(), it fails on the second loop.

This otherwise works when RTCS is not enabled.

Is there any explanation, or better yet, a fix or workaround?  This is very important to have both ethernet and flash update avaliable!!

Thanks

michael

[RadekS]

It is hard to say what could cause such strange behavior. I do not see more than one loop (one loop is while (0 == (ftfl_ptr->FSTAT & FTFL_FSTAT_CCIF_MASK))) in ftfl_flash_command_sequence() function, therefore I suppose that you mean that it crash when ftfl_flash_command_sequence() function is called second time.

Ideas:

1. When you call RTCS_create(...), RTCS functions will be added to project and this will increase project size. Are you sure that you don’t erase/rewrite code which is currently executed? If you use FlashX_swap, are you sure that your project image is smaller than 256kB? Please check start and end addresses of your project and compare it with flashX addresses.
2. When you want rewrite part of flash sector, you should be able allocate sector size in RAM. Are you sure that you have at least sector size (2kB) available in RAM memory?

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[michaelschwager]

A few more experiments:

1. I wrote a routine that keeps trying to write to the flash until all the bytes are written correctly, ie I keep reducing down the number of bytes I attempt, then if it succeeds, I move on, and then verify they were all written correctly. In most cases a few loop iterations are needed, but usually it work at around 120 bytes or less.

2. However I found that writing one 48-byte section adjacent to a previous 48-byte section will erase that 48-bytes section! I then have to go and try again.

3. Argh.

[michaelschwager]

Hi, thanks for the input. Yes I meant the second iteration through the loop. Here are some more points:

1. For writing calibration parameters (only 256 bytes), I open flashx:code and flashx:swap0, use SEEK_END to see how large the “file” size is, and compare total sizes to make sure I have enough space after the end of the image to write my 256 bytes. I write my 256 bytes at the end of flashx:swap0, which so far has always been much larger than flashx:code. Incidentally, I have also tried flax:swap1 and I still get the failure, so it doesn’t appear to be clobbering or overwriting its own image.

2. I have about 30k Bytes available in RAM, based on seeing how large lwmemalloc can go, so I’m not running out of memory.

3. According to the IAR introspection tool, I’m not overflowing the stacks in any tasks, and all the tasks appear to be healthy before and after a failed write attempt.

4. I have a test function (as opposed to the real API function which is buried a few layers deep) which attempts to write 256 bytes to the end of flashx:swap0 and I have put this at various points through the startup process. In all cases, it works initially, then after starting up some tasks, it eventually fails. In some of these cases, I don’t actually need to start RTCS_create(). It will fail after starting up one of the other subtasks. So this appears to be an issue between MQX tasks and the flashx driver; it appears it doesn’t actually have to be RTCS_create(). However, if I don’t link in the RTCS library, I don’t have the issue. So it kind of smells like it has to do with total size of the image, or maybe where the linker decides to put things.