CCS/TMS320F28379D: Advice for production programming (flashing, update, emulator, software etc)

Hi Jérémy,

To get you started, I would recommend checking out the following app note, which will get you started on flashing your device via the SCI protocol:

Serial Flash Programming

There are also examples of Flash Kernels for your device in C2000Ware that will help you get going. With the Serial Flash Programmer, you will be able to send pre-compiled C2000 Hex Files and program them into the Flash of your device without using CCS or an emulator (via the SCI protocol).

Let me know if this gets you going in the right direction.

Taumer

Hi Taumer,

Thank you for your reply, I have already started to read the principles but I have again lots of work !!

I will come back with other questions.

Thank you and have a nice day,
Jeremy

Hello everyone,

I have understood some things, I can now flash a kernel with sci_flash_kernel example, Idem for the blinky example. All via the console and .exe.

If I am right, the kernel "prepare" the SCI and the flash to receive the "real program" (blinky in this case), right ?

I have questions for clarify that :

1- Must we load the kernel each time before write the memory with the user program ?

2- How to manage and visualizing the used Flash memory (Is it possible to flashing kernel + custom code then write specific memory aera for constant values ?) ?

3- The  example take about 5min for flashing kernel, is it normal ? (I have entered 9600 bauds but if I right its take effect after there kernel flashing)

4- I have tryied the example on a F28377S  launchpad so I haven't access to the GPIO34 which is supposed blinking due to the example : so I have re-compiled the blinking example with corrected GPIO, I have used  hex2000 then serial flash programmer but this time I have the "Verify Error" at adress 00 when the application try to flashing the blinky project. Can you give me hints please ?

Thank you very much for your help and for your very efficient products.

Jérémy

Hello,

I can complete my post with another problem : I can flashing the F28377S launchpad but not the F28379D control card beacause the .exe stay on "Attempting autobaud to load kernel".

It's like there isn't SCI com', there are different points that I have tryied :

-> with my custom code running from flash I can send message via SCi ==> GPIO28-29 are effectively connected to the FTDI chip and the communication is working correctly

->I have tryied two kernel versions (F2837xD_sci_flash_kernels_cpu01 and F2837xD_sci_flash_kernels_cpu01_alt), logically the good one should be the second (gpio 28 29)

->I have tried multiple switch positions for SW1 and A:SW1 (I have disconnected emulator and boot modes seem to respond correctly).

Do you have any ideas and answers to my previous questions please ?

Thank you very much and have a nice day,
Jérémy

Hi Jeremy,

1- Must we load the kernel each time before write the memory with the user program ?

Yes, the kernel needs to be sent first to flash the device in this way.

2- How to manage and visualizing the used Flash memory (Is it possible to flashing kernel + custom code then write specific memory aera for constant values ?) ?

The Memory Browser within CCS (code composer studio) allows you to look at Flash memory locations and observe their contents. 

3- The  example take about 5min for flashing kernel, is it normal ? (I have entered 9600 bauds but if I right its take effect after there kernel flashing)

This is normal, sometimes the time it takes to flash via serial can be lengthy, but is expected.

4- I have tryied the example on a F28377S  launchpad so I haven't access to the GPIO34 which is supposed blinking due to the example : so I have re-compiled the blinking example with corrected GPIO, I have used  hex2000 then serial flash programmer but this time I have the "Verify Error" at adress 00 when the application try to flashing the blinky project. Can you give me hints please ?

Jeremy, could you give me more information on the error? Is the error from the serial flash programmer exe directly? Is it in the console? What output does the console have before the message appears? Have you tried using the "verbose" (-v) flag in your command to help with debugging?

Taumer

Hi Jeremy,

-> with my custom code running from flash I can send message via SCi ==> GPIO28-29 are effectively connected to the FTDI chip and the communication is working correctly

How have you determined this? Can you send an "A" to your launchpad and listen for an "A" back?

->I have tried multiple switch positions for SW1 and A:SW1 (I have disconnected emulator and boot modes seem to respond correctly).

What is your switch configuration? Have you ensured that the SCI boot mode is selected?

Taumer

Hi Taumer,

Thank you for your answer but I won't be at work until friday so I can't give you lots of details for the moment. What I can say is :

"4- I have tryied the example on a F28377S  launchpad so I haven't access to the GPIO34 which is supposed blinking due to the example : so I have re-compiled the blinking example with corrected GPIO, I have used  hex2000 then serial flash programmer but this time I have the "Verify Error" at adress 00 when the application try to flashing the blinky project. Can you give me hints please ?

Jeremy, could you give me more information on the error? Is the error from the serial flash programmer exe directly? Is it in the console? What output does the console have before the message appears? Have you tried using the "verbose" (-v) flag in your command to help with debugging?"

The error appears at the end of my code flashing (the kernel transfert is ok => I choose the first option => I see my HEX code transfert => at the end I have the message "ERROR_VERIFY", "error at adress 00"). I don't remember if I was in the verbose mode.

The Hex is comes from the blinky exemple project with modified GPIO number and recompiled without error.

I can give you more details on friday morning.

 

 

-> with my custom code running from flash I can send message via SCi ==> GPIO28-29 are effectively connected to the FTDI chip and the communication is working correctly

How have you determined this? Can you send an "A" to your launchpad and listen for an "A" back? My system has a state machine, I am displaying current state via SCI configured on GPIO28-29 so I suppose they are working correctly.

->I have tried multiple switch positions for SW1 and A:SW1 (I have disconnected emulator and boot modes seem to respond correctly).

What is your switch configuration? Have you ensured that the SCI boot mode is selected?

I am almost sure: on flash boot I can see my system working so I can validate the switch position for the "get mode" then I have only two combinaison, I have tryied both of them.

Thank you again for your help !!

 

Have a nice day,

Jérémy

Hi Taumer, I am sorry for my very delayed answer ...

So I have tryied to communicated with my F28379D (launchpad and control card) and nothing, the console stay stuck in "Attempting autobaud to load kernel". The only different point between F28379D cards and my F28377S Launchpad (which can autobaud) is the used GPIO for SCI.

F28379D launchpad => GPIO 42 and 43 : it doesn't work but it's in accordance with the sci boot options GPIO

F28379D control card => GPIO28 and 29 : I think I have to use "sci_kernel_alt", is what I am doing but nothing

F28377S launchpad => GPIO 84 and 85 : It works correctly, I think it is because the gpio 84 85 are the default sci gpio boot

Maybe I am missing something about gpio booting selection, is there something to do for choosing gpio 28 29 in more of choosing "alternative" option in kernel ?

You were right, I have forgotten to compile in FLASH mode !!

Thank you very much and have a nice day !

Jérémy

Hi Jeremy,

Just to clarify, when using the F28377S launchpad, things are working correctly? What are you seeing with the control card and F28379D launchpad? The same auto-baud error? Try opening a putty or similar window and sending an "A" to the F28379D after SCI is connected. What do you see as the response? If you do not receive an A then the cpu is not in SCI bootmode.

Taumer

Hi Taumer,

Yes everything is ok with the f28377S launchpad, and the autobaud problem is on the control and launchpad with F28379D.

I have tried to send an A with putty but I am not familiar with this kind of software. I know that f28377S is working good so I made my first test with it : on putty when I send "aa" the two leds of launchpad SCI flashing and the red led start to blinking, I think there is life.

But when I am connecting F28379D (launchpad or control card)  I can't write anything on the putty console and when I am pushing any key, the RX  led of the card is flashing one time.

I have tried all switch positions for booting (on the control card, Jtag is down, UART is up, and I have tested four possible combinaisons of boot switches).

Also, I have tried to connect putty with the f28379d control card and flash boot with my own code: I can see it working correctly (each change in the state machine is monitored in putty).

Thank you for your help and have a nice day.

Jérémy

Hello everyone,

Just for update my post, I haven't received notification for my previous post so I don't know if it is visible.

My problem still here.

Thank you for your help and have a nice day,

Jérémy

Hi Jeremy,

Sorry for the delayed response. Are you using the SCI_BOOT_ALTERNATE macro in the SCI_boot() function in the flash kernel? If so, you will also need to make sure you are using SCI_ALTERNATE boot, which will require you to boot your device in boot emulation mode.

Please let me know if this works for you.

Taumer

Jeremy,

What is the status now? Is it resolved?

Hi Taumer,

Thank you for revive my post, in fact I haven't seen your  previous post (As I said you I haven't received notification). I will try this but I think I will, in all the cases, design my board with the standard GPIOs.

I will make the test and I give you results,

Best regards,

Jérémy