Embedded TMS320C6000 Information Kick Off

Mike DunnOctober 25, 20072 comments

Before I get off on some embedded C6000 rant, I thought that I would try to express some of my background, interests and areas of expertise. Fast forwarding through vacuum tube and transistor computers, punched cards, 14 inch hard disks, delay line memory, RTL ICs, bit slice minicomputers, and an unknown number of microprocessors will almost get me from my past to the present. My computer life began in the hardware world, but the requirement for software [usually a few lines of machine code] quickly emerged. This was followed by simple asm programs, microcode, and firmware. Soon C, shell scripts, any eventually Perl were required to address the needs of current projects. I have left out several facts and details as my goal is to show a glimpse of my past to illustrate where I am coming from [I hope the grammar police do not come after me]. I obviously am not a 'CS type' and will not be expounding on DSP algorithms.

Most of my experience since late last century has been with the TI C6000 family DSPs. I plan to focus on some device differences/oddities and some of the problem analysis and debug that I have through. I am not sure if problems attract me or if I attract problems, but it seems that I have been getting involved in troubleshooting unusual problems throughout my career - and I always enjoy the challenge.

One of the reasons that I am doing this is related to my involvement with the Yahoo c6x group. Sometimes when I address a user question, I struggle with 'how much do I say'. I don't like to tell someone to 'just do this' without providing an explanation - and if I explain, I struggle with 'how much'. I strongly suspect that some of my topics will be triggered by some of those issues.

I realize that the size of the interested audience will probably be small, but that is ok.

Now, where shall I start...


[ - ]
Comment by MMarkJune 5, 2013
Hi, Mike

Project. Life locator for rescue operations(breathing detection).

Device consists of 2 parts.
User interface part - tablet.
Closed box with radar, all electronics, batteries and my DSP.
Communication - Wi-Fi

Problem. Update DSP firmware and run new version without system power reset.

Firmware is located in DSP flash.
So the first step is to send new version from tablet to DSP and
write it to DSP flash. It is OK.
The second step is more complicated. The idea is to use the same
boot loader that I use to load and run program. So I read boatload
from flash, pars it to RAM and readdress CPU to boot loader start address c_int00.
It doesn’t work if structure of firmware is changed.
It works if I length of program blocks isn't changed.

DM648, using ROM to boot. Fast boot. DSP\BIOS.

I use C code to reload new firmware to flash and reboot without power restart.

It is OK if I use old firmware as new (the same firmware is reloaded).

But if firmware is changed process is stuck in the custom routine Init_my_device() of BIOS.

1.Read and load new firmware to flash instead of running one.
2.Close all my threads (I have 3 now).
3.From Idle_loop routine read “my” boot loader from flash, pars it to RAM, clean all cashes and start it from its c_int00.
Boot loader reads new firmware from flash, parses it to DDR and runs it from its c_int00.

I guess memory distribution is changed but I didn’t update some registers.

Can you help what I missed?


This staff works with "reset" perfectly.

If I read “my” boot loader and … from one of my threads it is OK more often then failed.

If I read “my” boot loader and … from Idle_loop it is failed allways.

About me.
I have 30+ experience to work with numerous micro. MicroChip mostly.
Last 5+ years DM648. My part is system structure, algorithms, programming and testing.
So I am 1 for whole project (soft).

[ - ]
Comment by mikedunnJune 9, 2013
Sorry about the delay...
Problem - Code works from reset but not when dynamically reloaded.
RE: "from flash, pars it to RAM and readdress CPU to boot loader start address c_int00."
1. Does "readdress CPU" mean 'branch to' or are you writing the PC?? If you are writing the PC, the pipeline is not getting flushed and you need to execute 6 or 8 separate NOPs or execute a Branch.
2. If the apps set the ISTP, the boot loader may assume that it is at 0.


To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: