SmartRF04EB unable to load a program

Hi,

IAR will lock the flash pages if the "Lock flash memory" option is enabled (Project > Options > Debugger > Texas Instruments > Flash lock protection). If this option is disabled, the flash pages should not be locked. A mass erase (the Erase option in the SmartRF Flash Programmer) will however undo this. 

So, if I've understood the issue correctly: You have 2 SmartRF04EB (1 and 2), and two CC251x (A and B). 04EB #1 fails to program chip A, while 04EB #2 may program both chip A and B. Is this correct? After erasing chip A using 04EB #2, are you able to program it using 04EB #1?

You should double check that the jumper settings on both 04EBs are identical and that the power strap is present (P5). If you have a scope present, do you see a difference in signal integrity on the two 04EBs?

Br,
ABO 

Thank you for your answer. Your questions inspired me to do some tests, that I will describe here.

First, to clarify :

TIABO said:

So, if I've understood the issue correctly: You have 2 SmartRF04EB (1 and 2), and two CC251x (A and B). 04EB #1 fails to program chip A, while 04EB #2 may program both chip A and B. Is this correct?

A little mistake : 04EB 1 has problems in programming both chips, whereas 04EB 2 succeeds at programming them. But I'll explain it in more detail.

The reason I feared IAR might have caused the problem in the first place was that the first thing I tried on 04EB 1 was to program the chip using IAR. This proved unsuccessful : when pressing Download and Debug, IAR warns us that the device is debug locked and needs to be erased, suggesting to erase it right now by pressing OK. Pressing OK, the downloading process happens, but produces a ton of verification warnings, all related to the fact that a huge list of bytes end up being equal to 0xFF on the chip (which they shouldn't be). Also, the chip doesn't run the program I told IAR to download.

After experimenting with the Flash Programmer for quite a while on both boards, I finally tried to program the chips via IAR on 04EB 2 (same project and related settings) and everything worked normally. So I'd be really surprised if the problem turns out to be caused by IAR.

So at least we know that we can program both chips without any problem via 04EB2. Still, it would be pleasant if we could figure out how to make 04EB 1 work. I made some discoveries but I still can't pinpoint the cause of the problem. These discoveries all relate to behavior with the Flash Programmer, and will be described here.

Methodology

---------------------------------------------------------------------

04EB2 succeeds at all Flash Programmer functionalities, with both interface speeds. 04EB1 has a very limited capacity with the Flash Programmer. Trying to read or verify (including ''Erase, Program and verify'') the chip's contents always ends up in a ''Device Is Locked, You Have to Erase the Flash'' problem (which is logical, of course, as erasing the chip removes all possible locks on it). However, it turns out that 04EB1 is unable to erase the chip. With Interface on Fast, it sends us an error message saying that the Flash Erase failed. Trying to ''Erase'' or ''Erase and Program'' with interface on Slow sends a success message. I had my doubts about this success message, so I tested it with the following procedure  :

1- The chip is erased (with the 04EB2, of course).

2- Program the chip with 04EB1, using the Flash Programmer with Interface on Slow and the ''Erase And Program'' command (as Erase, Program And Verify will send an error message). The program is the hex file for the PER example, provided on TI's website. It visibly doesn't run.

3- Replace 04EB1 with 04EB2. Read the chip's flash to Hex file A, run ''Erase And Program'', and then read the results in Hex file B.

4- Result 1 : 04EB2's program is visibly functional, and code is fully copied to the chip (seeing Hex file B). 04EB1's program is visibly unfunctional, and that can be explained by the fact that the code stops at address 07F0 in the hex file (corresponding to 2K of code, or two pages). Up to this point, it is exactly similar to 04EB2's correct output.

5- Replace 04Eb2 with 04EB1. ''Erase and Program'' with a small code (a timer example, roughly 200 bytes in size). The program doesn'tstart running.

6- Replace 04EB1 with 04EB2. Same thing : compare 04EB1's output with 04EB2's. As can be seen, 04EB2's program works, and examination of 04EB1's hex file reveals that the previous program on the chip (the correct PER example installed there in step 4) wasn't erased; 04EB1 just put the timer code at the start of the PER code, and the combination of the two is somewhat different from the correct timer code.

7- Erase the chip via 04EB2.

8- ''Erase And Program'' the chip with the timer code using 04EB1.

9- Rerun the hex file comparison. Result : both boards produce a correct output.

Conclusions

---------------------------------------------------------------------------

These tests and some others lead me to conclude that :

1- Once again, 04Eb2 succeeds in all situations

2- 04EB1 can download a working program the the chip, provided it is less than 2K in size.

3- 04EB1 cannot erase a chip.

4- 04EB1 mistakenly assumes the chip is debug locked.

My hypotheses on all of this :

1- The problem could be electrical in nature, but these tests make it more seem like some kind of software bug. That's why I didn't try the oscilloscope on the board yet.

 2- I downloaded the latest firmware update (0045) on 04EB1 (the unfunctional one), but not on 04EB2 (it still has 0043). That might be a cause; HOWEVER, I remember that the troubles started on 04EB1 before I downloaded this update.

I hope this helps in finding the problem. Once again, thanks in advance for your answers.

DPC

Hi, thanks for the detailed description.

It definitely sounds like something is wrong with 04EB #1. As far as I can see, two possible options are likely.

1) The MCU on 04EB #1 is somehow damaged and does not work correctly.

2) There is a poor connection between the 04EB #1 MCU and the CC251xEM.

To test the second option, it would be great if you could compare the signal integrity between the two 04EBs.

As to the firmware, we do not have any reported bugs on the latest 04EB firmware (0045), so I do not think that is the case. I have attached revision 0043 of the 04EB firmware in case you wish to try a roll-back anyways.

Hi and thanks again for the support.

I tried to do an ''Erase, Program and Verify'' with 04EB1 this morning and it worked (that is,a more-than-2K program safely ended up on the chip), but only once. All other attempts ended up with results similar to those exposed in my previous message, both in the Flash Programmer and IAR.

I also downgraded my firmware with the file you provided, but this changed nothing (as expected, actually). At least, it shows that the interface used to program the board works properly. I checked again and all jumper/power selection settings on the boards are the same. After all, we received the Dev Kit last Friday, and began programming with it (or trying to, in 04EB1's case) last Monday.

The non-repeatability of errors leads me to believe that the bug may be hardware-based after all. I'll check out what I can do with the equipment we have here. In investigating possibility #2, do you have any suggestions on which signal(s) I should monitor in priority?

Finally, even if we manage to pinpoint the cause of the problem using hardware debugging, we might not be able to solve it. That is, we will maybe end up having to get the board replaced or repaired either way. Does TI provide replacement/repair in such situations?

Hi,

The signals that are interesting are the debug clock (DC) and debug data (DD) lines. You may also monitor the CC251x's RESETn line. To get the defective SmartRF04EB replaced, contact your local TI representative.

Br,
ABO