CCS/TMS320F2812: Flash works one day and next day not

Michiel,

this error occurs when the emulator cannot reach the device. This can happen for several reasons, but usually is because the device is in a state where it cannot reply to commands sent from the emulator.

The "low-power mode" is referring to a C2000 operating mode. This is where the device will shut down many of the unneeded circuits to save power. Are you using a Low-Power Mode (LPM) in your code?

A good first step is to put the device in "wait-boot mode". This is done by holding a high or low value on several of the device pins while powering up. The full details on the procedure are outlined in the TMS320x281x DSP Boot ROM Reference Guide. Table 4 should be helpful for you.

Regards,
Cody 

Hi Cody,

thank you for your reply. I forgot to mention that I'm using an eZdsp board, so I think I should be able to select the boot load mode with the jumpers on the board. Right now they are JP1: 2-3 position,JP4: no connect, JP5: 1-2, JP7: 1-2, JP8: 2-3, JP9: 1-2, JP11: 1-2, JP12: 2-3. I think JP7 selects the FLASH mode (table 13 in the ezDsp Technical Reference 6735.ezdspTM320F2812.pdf looks similar to table 4 in the TMS320x281x DSP Boot ROM Reference Guide), so  I think I am in the right boot mode (although I'm not quite sure yet what the branch instruction is that is mentioned in table 4). I also  don't know what you mean by a low power mode. Does this correspond to any of the modes in table 4? And which mode would correspond to a 'wait-boot mode'?

On the other hand, strangely enough, sometimes I can flash the DSP in a few minutes, sometimes it takes more than an hour and sometimes it does not work at all. How can that happen if I always boot in the same mode (regardless whether it is the right mode)?

Best regards, Michiel.

Hi Cody,

I looked into the Reference Guide you sent me and I have a few more questions. I guess I don't really know the loading procedure. When I first run 'Debug' in CCS the *.out file will be uploaded to the target irrespective of the settings of the jumpers on the eZdsp board right? Or do I need to select 'microcomputer mode' for jumper 1? The strange thing is that 'microcomputer mode' in the eZdsp Technical Reference Guide I sent you corresponds to XMPNMC=0 while in the document you sent me it corresponds to XMPNMC=1. Do you know what is going on there? And then after the upload, do I need to change the jumper 1 setting, so that after a reset the target will boot internally?
I did not write the code myself, so I am wondering how the branch instruction is included in the project. I think this is a so called .asm file, but how I need to implement and write the code for it I don't know. Do you have some kind of application note for that?

Best regards, Michiel.

Michiel,

        SPI mode can work as a "wait-boot mode" the device will wait for commands to be sent over SPI, which you wont provide, so the device will wait and not run any code that you have programmed.

The standard mode is microcomputer mode(XMP/MC = 0), the differences are described in the data sheet for the device. I am not sure why they would be different. This is a one time selection you will not need to change it again.

The linker command file will place segments of code in memory. 

I think you will find our multi-day workshop very helpful.  

http://processors.wiki.ti.com/index.php/C2000_Archived_Workshops 

(hopefully I didn't miss any of your questions)

Regards,
Cody 

Hi Cody,

thank you for your reply. I actually remembered that I had downloaded a multi-day workshop before, although I think it is actually a different one (TMS320F2812 Digital signal processor-Implementation tutorial). I have used that quite extensively, but I never really looked into the boot loader details, because in the past the code uploaded to the target without a problem most of the time.

You answered all the questions. I think I forgot to answer one of your questions. You asked whether I use Low power mode in my code. What do you mean by low pwer mode? Are there special functions for low power mode (as I said the code has been written by someone else so I might not know about all the functions he used).

Since the code is uploading every now and then I almost start to think that the JTAG probe has reached its end-of-life, since it was a hand-me-down to begin with. Which JTAG (to USB) probe would you recommend to purchase? I think the XDS110 JTAG Debug probe seems like a good option for me.

Best regards, Michiel.

Michiel,

the low power modes are a device configuration. Look in the System Control and Interrupts reference guide.

These modes turn off clocks inside of the device to save power, if the emulator attempts to connect to the device while it is in a low power mode it will not be able to respond.

I have never worn out an debug probe. it is possible for them to be damaged, but they are pretty robust.

Regards,
Cody 

Hi Cody,

thank you for your reply. Actually I found the low power mode registers in the mulit-day C28x Workshop you refered to before. I searched the project for LPMCR and I only found it in the example files and in the include file DSP281x_SysCtrl.h, so it is not used in my project.

Yesterday I've been able to load the program to the target multiple times without a proble, except that it takes literally more than hour. Loading the program in the FLASH mode or the SPI mode did not make a difference.

The debug probe that I've been using is actually a TI Docking Station USB-EMU R3 with a home made JTAG cable and some soldering to the Docking Station, so I don't know how reliable that is. Moreover, I think the XDS110 JTAG Debug probe can handle higher bit rates, which is much appreciated seeing that I have to wait an hour now.

Best regards, Michiel.

Michiel,

with a large code size and a slow emulator it shouldn't take an hour to reprogram the device. It sounds like it you are having a bottle neck somewhere, It could be the PC, the emulator, any isolator you may have, or even the c2000 device.

The XDS110 is a good emulator and I think you would be happy with it, but it may not fix your problem.

From a C2000 perspective how may times has the device been reprogrammed? Has the device used the Flash API in the past to maybe rewrite itself many many times?

There are some Code issues and settings in CCS that can also affect flash erase/program time, check these threads.( disregard the part about the "free version" of CCS, they are all free now)

https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/438222/1597057  

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/404723 

Regards,
Cody 

Hi Cody,

thank you for your reply. I know, an hour is way too long, but I was happy it was working again:) It is a large program (83 kB), but an hour is not right. Last week I could program the target in just a few minutes.That's the thing, it changes all the time. I don't think it is the C2000 device, because I have the same issue with several eZdsp boards. The c2000 chips have been programmed several times (max a hundred times I would say), but definetely not thousands of times.

It could be the emulator, like I said, the JTAG cable has been home made. However, it could also be the fact that I run CCS under VMware and I use a USB3.0 to USB2.0 adapter for the USB cable to the emulator board. The problem is that I have to run dedicated software under VMware, because the company does not allow employees to install software on their laptops.

I looked at the links to the threads and I'll try some of the suggestions. It is pretty much like in the first post (unfortunately I didn't see the solution in the post), it is waiting for about 15 minutes at .text and then flashes it to 38% and then waits another 15 minutes, and so on. I don't think reinstalling CCS7 is going to help, because I had this issue ever since I installed it the first time. I guess I'll try the other things one at a time to see if it will make a difference.

Best regards, Michiel.

Michiel,
it seems like the issue is not part of the eZDSP, but you should check the voltage on the board, it can affect the flash erase/programming times.

Does both Programming and Erasing take a long time?

Regards,
Cody

Hi Cody,

flashing usually doesn't take too long: I would say 30 sec. I assume you mean that I should check the 5V power supply voltage?

Best regards, Michiel.

Michiel,
when flashing the device takes a long time, how much time is spent erasing the device? How much time is spent programming it?

I would like you to check the 3.3V supply at the device, the 5V input will be brought down to 3.3V which powers the flash. If a component has been damaged it is possible that maybe the device is only seeing 3.0V which would result in longer erase/ program times. While you are checking voltages it would also be a good idea to check the core voltage as well(should be ~-1.9V).

Regards,
Cody

Hi Cody,

sorry, that was a typo: I meant to say that erasing the flash sectors doesn't take too long (usually about 30 sec), the rest of the hour is spent on loading the program. I checked the 5 V voltage on the board and that was 5.024 V, so that doesn't seem to be a problem. I'll check the 3.3 V and 1.9 V (if I can find out where to measure this) as well.

Best regards, Michiel.

Hi Cody,

I checked the 3.3 V on e.g. the JP7 jumper (FLASH mode) on the eZdsp and this voltage is 3.304 V, so I guess that is ok. I think I could measure the core voltage on one of the pins of U14, which I think is the clock circuit for the core on the eZdsp. It is an IC with 5 pins, one of them was +1.846 V (2 were GND, one 0.746 V and one 1.637 V). Did you say it should be -1.9 V (negative)?

Best regards, Michiel.

Michiel,

sorry that was a typo, I was going to write 1.8-1.9V some of the F281x parts run at 1.8 and others run at 1.9. I don't think that 1.84V is a problem.

3.3V should also be OK.

Do you have a separate computer you could try to program the device? It may be a driver problem that is causing it to slow down.

Regards,
Cody 

Hi Cody,

that is the issue here, my company will not allow me to use my own computer (with USB2.0 port and admin rights), so I am stuck with running CCS under VMware and a USB3.0 to USB2.0 adapter. I ordered the XD110 Debug probe, so next time I need to flash the DSP I can use it and the suggestions in the threads you referred to.

Best regards, Michiel.

Michiel,
Why are you using a USB3.0 to USB2.0 adapter? USB3.0 ports are backwards compatable...put the long way they are capable of delivering more power and higher data rates than USB2.0, if you use a USB2.0 device in a USB3.0 port it should work without issue. Is there an issue i'm not aware of?


Thanks!
Cody

Hi Cody,

I'm sorry, ýou're totally correct. It is an extension cable USB2.0 to USB2.0. If I plug the Debug probe into a USB3.0 port it makes no difference.

Best regards, Michiel.

Michiel, 

I would like to point out that VMware could be causing the issue as well, it can be slower compared to simply running an OS.

Regards,
Cody 

Michiel,
Have you came to any resolution?

Regards,
Cody

Michiel,
I am glad to hear that your issue is resolved! Feel free to start another post if you have anymore issues!

Regards,
Cody