TMS320F28379D: Professional programming in mass production

Sorry to hear of your poor experience. There are lot of components involved. Some could be hardware issues, some are related to the Flash Programmer, some with the tools. Thank you for sharing your feedback with the various threads you have created.

Hi Ki,

Today I fixed more than 20 boards in CCS. You told me that it uses another API (which one? Can I use that?)

The main differences to DSLite was, that I kept one open session for all operations (with DSLite I use 4 calls).

Nevertheless with CCS I had significant number of issues, ot following types:

1) [x3 different boards] when I programmed OTP for cpu1 (last of 4 steps in my sequence) it returned an error:

I thought, that I by mistake selected another core (or CCS did that - CCS switches between them during operations), but no. I double checked and it was right. Though I selected cpu1, CCS was trying to program cpu2, that is already programmed, hence the error!

2) [x1] when I tried to calculate checksums for cores I had:

after erasing flashes in both cpus it worked fine.

What is the most generic way to program (or even to send to RAM) and run a program that I can handle myself?

Is it DebugServer? Can you share with me some documentation on this topic?

Ki said:

There are lot of components involved. Some could be hardware issues, some are related to the Flash Programmer, some with the tools.

I also perceive this multilayer structure as a potential source of problems. That is why I am trying to limit the number of components and isolate the root cause.

Regards,

Piotr Romaniuk

PS
I examined flash contents and found that boards with incerrect checksums of flash have repeatible errors (like: only one sector was programmed; specific, the same  value is not programmed correctly.) 

Piotr Romaniuk said:

You told me that it uses another API (which one? Can I use that?)

Sorry but I may be getting some of the thread mixed up. Which API are you referring to?

For #1: 

Piotr Romaniuk said:

I thought, that I by mistake selected another core (or CCS did that - CCS switches between them during operations), but no. I double checked and it was right. Though I selected cpu1, CCS was trying to program cpu2, that is already programmed, hence the error!

I used the F28379D fairly often and had not ever seen where (in CCS) I selected CPU1 in the Debug view but it programs CPU2 during a load program operation. As you mentioned, sometimes the debugger will switch debug context due to cross triggering and such but as long as the proper CPU is still highlighted in the Debug view, then debug operations should just apply to that CPU unless some synchronous group is used.

As for #2, I'm not sure of the issue there. My expertise is specific to the host software like CCS or UniFlash but the flash programmer itself and the hardware behavior is beyond my area of expertise. Charles (in your other thread) is more proficient in those areas. Perhaps inquire with him these extra details regarding #2 and leave this thread for the clear CCS ones like #1.

Piotr Romaniuk said:

What is the most generic way to program (or even to send to RAM) and run a program that I can handle myself?

Working with RAM is easier. You would need to modify the linker command file to make sure that the code is configured to load and run from RAM:

https://dev.ti.com/tirex/explore/node?node=A__APJQ1q8Ox6tOF4TmB4THeg__ccs_devtools__FUz-xrs__LATEST

Then you can build and debug your project normally in CCS. The debugger will load t he program to RAM.

Hi Ki,

thank you for the response. I will reply later because I am involved in writing RAM-based bootloader.

Kind regards,

Piotr Romaniuk

Hi Ki,

Ki said:

Piotr Romaniuk said:

You told me that it uses another API (which one? Can I use that?)

Sorry but I may be getting some of the thread mixed up. Which API are you referring to?

I asked about CCS debug perspective.

Ki said:

I used the F28379D fairly often and had not ever seen where (in CCS) I selected CPU1 in the Debug view but it programs CPU2 during a load program operation. As you mentioned, sometimes the debugger will switch debug context due to cross triggering and such but as long as the proper CPU is still highlighted in the Debug view, then debug operations should just apply to that CPU unless some synchronous group is used.

I had another experienses.
For example, I saw once discrepancy between window with debug server connection and selected core in CPU-Flash window (that one where DCSM parameters are entered, flash erase button is, etc.).

The issue I described, i.e. unexpected switching to another core, happened 3 times on different boards. I performed the operations in very systematic way with writing down all steps in excell sheet. 

According to programming from RAM loaded pre-bootloader it works very good, no errors in programming.
Hence, the conclussion is that there are some issues with DSLite, they are probably related to multiple sessions (a history between sessions or missing synchronization of items).

Looking from mass production perspective there are two goals:

1) low programming failure rate, 

2) short time of programming.

For me, [1] is achieved. 
Unfortunatelly process of loading prorgam into RAM takes very long. The code is about 30KB and process of loading it by DSS takes 30 seconds.
JTAG works with 5MHz clock so it means that there is somewhere huge overhead.

I will open another theat for that issue.

Regards,
Piotr Romaniuk

PS
My initial question: "How to do mass programming in production?" is still open.