TMS320F28035: can bootloader

Hello,

Does this behavior occur when you run the example CAN flash kernel for F2803x in C2000Ware? It is located at C2000Ware_5_02_00_00\device_support\f2803x\examples\c28\f2803x_can_flash_kernel

Kind regards,

Skyler

I am modifying an example program, but during mass production, about 1/4 of the ICs have issues. The problem is caused by illegal interrupts, which occur each time the buffer reaches its threshold.

Hi Lin,

What is the size of the buffer when it is reaching its threshold?

Thanks and regards,

Charles

buffer = 0x400

If different boards have the following structure:

struct HEADER { Uint16 BlockSize; Uint32 DestAddr; Uint32 ProgBuffAddr; } BlockHeader;

will the data be the same? The same code.

I found an issue that whenever I switch to a different MCU, the CAN bootloader works.

Hi Lin,

I'll need some more time to look into the differences between this device CAN bootloader and the others, will get back to you within the next day or two.

Thanks and regards,

Charles

Thank you

Is it possible that there is a memory issue? However, the JTAG works fine.

Hi Lin,

To see if there are memory constraints, first check the application's .map file, located in the CPU1_FLASH folder for the built project. 

Here you can see what the size of the flash application will be that is going into Flash memory.

Is it able to load the entire application file? Can check the flash memory window in CCS to confirm. Also, what host programmer are you using to send the application file?

Thanks and regards,

Charles

Lin,

            I presume you are using the CAN bootloader to update your firmware. I see the Watchdog (WD) is disabled in your main code. However, once the Flash is erased (i.e. all 0xFFFF) and the CPU attempts to “execute” that, an illegal ISR for unimplemented opcode would be invoked. If you simply apply power to a device with a blank Flash, the device will keep on resetting because the WD counter will keep overflowing.

lin hong said:

Here is the configuration of my flash.cmd file. I'm not sure if this is the issue.

If it is a problem with the linker command file, you should see this in every device, not just in 1/4^th of the devices. 

On a device that failed the Flash update process, are you able to connect to the device via CCS and re-program the Flash through JTAG?

Lin,

            In order to help you better, can you please answer the below questions?

1. How long has this design been in production? Or is it yet to go into production?
2. If this design is in production, how many boards have been shipped with this device till date?
3. In exactly how many boards is this problem seen? What is the DPPM value?
4. In a board where the problem is seen, is the problem intermittent or permanent?
5. If the problem is intermittent, how often is it seen?
6. Is it possible to reproduce the problem easily and consistently?
7. Is this seen in a device that has been working fine for some time? If so, how long?
8. What is the exact nature of failure?
9. Would you be willing to share the schematics with us? You can send it through a private message and not post it on the forum.

circuit diagrams?

Lin,

    I have sent you a friendship request. Once you accept it, you can send the schematics (circuit diagram) to  me privately. Please answer every question I have asked in my previous post clearly. 

I checked and the limit is not exceeded

Lin,

          Please answer questions 1 to 8 and also the below question: 

On a device that failed the Flash update process, are you able to connect to the device via CCS and re-program the Flash through JTAG?