TMS320F2812: Flash API Issues

Hello,

Apologies for the delay, yesterday was a holiday in the US. Please expect a reply within the next day.

Best,
Matt

Luke,

Can you confirm which boot mode you are using to download the flash kernel/data:

Uniflash will use JTAG pins to download the kernel/API and data, where your production with FPGA will use one of the other modes, SPI, SCI, or parallel boot.

Thinking about FPGA(external changes) here's where I would start looking:

1)Boot pins, we need to make sure the below pins are driven properly for some duration after power up, so the BROM will correctly identify the Boot Mode.  Can we make sure the pins are held at the same state after XRSn de-asserts for both old a new FPGAs?

2)Clock: Since you mention slower frequency can work, let's make sure the input clock to the device hasn't changed with FPGA change.  I don't think this is the issue, since Uniflash would use this same clock, and potentially have the same issue if it has changed...but good to confirm

3)comms protocol, whatever boot loader is getting used, the data will need to be presented per the peripheral listed.  If this changed from FPGA, then it may cause issues...although I would think you'd get some type of bad code and flash API might not run at all...

Will look for your reply.

Best,

Matthew

1)Boot pins:

Set for Jump to Flash address 0x3F7FF6. SCITXDA is drive high by the FPGA. Monitored all the pins and didn't see them change state during the programming.

2)Clock:

This is the same between the designs. It has a 32Mhz oscillator that feeds an inverter that is used to level shift it to 1.8V.

3)It use the same design as the old. It use the XINTF.  The FPGA uses block RAM to send the address, one word of data and control signal. 

I have verified with a debug build of the bootloader that the address and the data match what has been sent.

The routine:

• reads the block ram and stores into local variables.
• checks the control word variable (if non zero it writes, if all F's it done)
• Programs the one word using the data and address variables.
• If program success, verify data. If not send the FPGA return code
• If verify success,  If not send the FPGA return code
• write the control word of 0x0000, so FPGA know to send next word/address.

I have done test routines in debug where if the program API returns with error and than the verify fails and then I check the ActualData returned from the verify API. If this data is 0xFFFF, try the write again. I have seen it correctly write and verify the second time, but this doesn't always work either.

Luke,

Are you observing this on more than one F281x device, i.e. do you have option to try on a different PCB to see if the fail is across all F281x or just isolated to one device.  I just want to rule out a bad MCU.

The interesting thing here is that when the program/verify fail, the data in the flash is still in the erased state, and not some intermediary failure based on the data that was to be written.  And that if you re-attempt the program it may work, I don't think the issue is in the flash itself, else we would be seeing something different that 0xFFFF.

But since the program fails, I have to assume the data from the FPGA is received correctly before the program operation, else the program would pass and the verify would fail.

Any chance the FPGA is somehow interrupting the API call(INTs should be disabled in the API though)?

Best,

Matthew

Matt,

We first noticed it because 5 boards at of 22 batch run had this issue. When loading the application firmware on the those 5 boards, we noticed it wouldn't always fail. However multiple tries would cause it fail and the location in the flash when it failed is random.  The other 17 boards we flashed 10 times, testing to see if they also had the issue, but they succeeded every time.

Last week we received new batch of PCB and run a small sample batch of boards (3). 1 out of the 3 are experiencing the same issue.

The FPGA should only be sending an interrupt when it write "command" register. However I can check this to see if it is misbehaving. 

Is there any debug information that I can gather that would be useful to tell why the API operations are failing?