F28035 Flash API V1.0 Crashes

We have determined that the problem occurs when the words to be programmed include words that are 0xFFFF.

If we change values to be programmed from 0xFFFF to 0x0, the programming success in both case (16 words and 2 words).

So we may have a temporary workaround. 

Since there is probably a branch around programming words that are 0xFFFF and never need to be programmed, perhaps there is a firmware bug along that path in the API code.

We have confirmed that avoiding programming ANY words that are 0xFFFF will solve the issue. We modified our in-system programming to program single words on a word by word basis, skipping any words that are 0xFFFF, works without any crashes and the programming time isn't much longer. 

The issue remains that the flash API in the ROM is broken and can crash when programming a multiple word buffer when the buffer contains words that are 0xFFFF (or perhaps only when the first word is 0xFFFF as in both of our examples).

Wally Ritchie said:

We have confirmed that avoiding programming ANY words that are 0xFFFF will solve the issue. We modified our in-system programming to program single words on a word by word basis, skipping any words that are 0xFFFF, works without any crashes and the programming time isn't much longer. 

The issue remains that the flash API in the ROM is broken and can crash when programming a multiple word buffer when the buffer contains words that are 0xFFFF (or perhaps only when the first word is 0xFFFF as in both of our examples).

 

Wally,

I wanted to see if this is still an issue. 

When the API crashes does it mean it never returns or it returns an error code?  If the latter, can you tell me the error code?

Regards,

-Lori

It's not an issue for us anymore because the work around solves our ISP issue.

There is no return from the API and no callback. When you call the the API, it ends of disconnecting the emulator (if attached), which is something we usually only see when power is glitched. (We have plenty of power so that isn't an issue). If no emulator is attached, the chip just hangs until power is recycled (or our hardware watchdog bites it). 

Wally Ritchie said:

There is no return from the API and no callback. When you call the the API, it ends of disconnecting the emulator (if attached), which is something we usually only see when power is glitched. (We have plenty of power so that isn't an issue). If no emulator is attached, the chip just hangs until power is recycled (or our hardware watchdog bites it). 

Hi Wally,

I would like to reproduce this issue if possible but so far have not been able to do so.  Let me tell you what I tried and maybe you can tell me if I'm missing something.

I am using a 28035 on a control card.  I took the example that comes with the V100 flash API and modified it as shown below.  The call returns and the buffer was properly programmed.  I believe I am using the same flash address and data as you had issues with.  Let me know your thoughts.

I'll dig out a control card and see if I can reproduce the issue there. All of our control cards, however, are TMX. Did you do your testing with a TMS?

The only differences I can think of off-hand are the CPU timing (we run full speed at 60MHz) and the fact that we run out of FLASH (our ISP code is stored on FLASH segment A.)  

Our Call-back code is in RAM, but perhaps there is some issue on re-enabling flash after the program call where it is not quite ready to execute.

It doesn't make sense for you to look any further until we can reproduce the issue on a control card.

Thanks

Wally,

Wally Ritchie said:

I'll dig out a control card and see if I can reproduce the issue there. All of our control cards, however, are TMX. Did you do your testing with a TMS?

I used a TMX part as well.

Wally Ritchie said:

The only differences I can think of off-hand are the CPU timing (we run full speed at 60MHz) and the fact that we run out of FLASH (our ISP code is stored on FLASH segment A.)  

Our Call-back code is in RAM, but perhaps there is some issue on re-enabling flash after the program call where it is not quite ready to execute.

My code was loaded into flash but executed in RAM.   I'll re-arrange my memory map and try calling the API from code in Flash itself.

-Lori

Wally,

Looks like I've been able to reproduce the problem.  Thank you for the tip. One difference is I can reproduce the problem even if all values in my buffer are non 0xFFFF.

First analysis seems to be the CPU is going into the ITRAP without doing any programming.   I need to do some more analysis to figure out exactly where the issue is and how the CPU got there.  

Calling the API from a function which itself is executing in RAM appears to be a work-around at this time. 

Regards

Lori

Scary if it fails with non-0xffff values because we haven't yet seen that (with TMS parts).

To provide some additional margin, I will call the Programming function through a RAM function and maybe add some additional delay before returning to FLASH.

Thanks

Wally Ritchie said:

Scary if it fails with non-0xffff values because we haven't yet seen that (with TMS parts).

To provide some additional margin, I will call the Programming function through a RAM function and maybe add some additional delay before returning to FLASH.

 

Thanks

Wally,

I was able to spend more time looking at this today in more detail.  I made a mistake yesterday.   When I moved my calling function to flash I also moved my callback function to flash - which of course is not allowed.  This was causing the ITRAP that I saw.

Fortunately, that explains why I saw an issue even with non0xFFFF data.  Unfortunately this means I'm back to not being able to reproduce the problem.  

-Lori

At least this isn't as scary since we haven't seen any failures programming other than 0xffff blocks.

I'll try to see if I can reproduce the problem on a control card.

It looks like our original problem may have been caused by an access to PartIdRegs.PARTID.all.

Although it looks like a register, this actually appears to be a location in OTP memory. Thus it cannot be accessed from the call back. We used this location to determine what GPIO bits feed our external watchdog which varies between 64 and 80 pin parts. During a long ERASE operation, the part number comes back other than its correct value, so we end up kicking the wrong dog. I suspect that sometimes during programming, a similar thing happens.

I can't find any reference to this in the Flash2803x_API_Readme.pdf. It might be worthwhile to put a caution there not to read any of the data from 0x3f7c00 - 0x3f7fff.