I'm having a problem with the MC13213 SRB units from the...

[fgs_chuck]

I'm having a problem with the MC13213 SRB units from the network evaluation kit. I started with the SMAC Accelerometer example generated from BeeKit. I added some code to decode XML packets and modified the SCI code to use 19200 Baud instead of the default 38400 Baud. After downloading the code to the SRB with the USB Multilink, the device acts like it is fried. It gives me a download error and will not boot or download any other S19 file. I don't know what the problem is, but I need to know how to bring these units back to life.

At first I thought it was a problem with the USB Multilink. But, I got access to another Multilink, and it is not the problem. Does anyone have any ideas on how to bring these boards back to life?

To get 19200 Baud operation, I added the following line in SCI.h:

#define BAUD_19200    0x1A    //for busclk=8Mhz (clk rate=16Mhz)

And changed the following line in SCIInit() in SCI.c:

SCIBDL = BAUD_19200;



Regards,
Chuck

[FlyFisherman]

Hi fgs_chuck,

I would like to know if you are able to download other program or not (or erase the memory of the chip)?

If the first question is yes, way not generate a new project with BeeKit with the 19200 baud rate? In this way you can check if your board is still working well and after you can paste your code in the new project.


Regards
FlyFisherman

[fgs_chuck]

FlyFisherman,

Thanks for your response. Once the offending program was downloaded to the SRB, it was not possible to use the Test Tool to download any other S19 file to the unit.

The local Freescale rep suggested that I use the CodeWarrior debugger to download a different program, and that approach worked. Once a different program was programmed via the debugger, then the unit could be re-programmed with the debugger or the Test Tool app. This surprised me because both the Test Tool and the CodeWarrior debugger use the same BDM module for programming the Flash. Does this mean that the Test Tool program that Freescale ships is unreliable? I don't know. It seems a bit inconsistent.


Regards,
Chuck

[FlyFisherman]

Chuck,

>Thanks for your response. Once the offending program was downloaded to the SRB, it was not possible >to use the Test Tool to download any other S19 file to the unit.

Do you use a bootloader? When you open the test tool you contact the bootloader and after you download a 15.4 program .... correct me if I'm wrong!!
The (offending) program  you had downloaded may have over-written some data in the bootloader's section. If this happened, when you have tried to contact the bootloader for a second time it wasn't able to respond!!

>The local Freescale rep suggested that I use the CodeWarrior debugger to download a different >program, and that approach worked. Once a different program was programmed via the debugger, then >the unit could be re-programmed with the debugger or the Test Tool app.This surprised me because >both the Test Tool and the CodeWarrior debugger use the same BDM module for programming the >Flash.

But have you downloaded a program which works well? What does happen if you download the offending  program? Does the board still work well?

>Does this mean that the Test Tool program that Freescale ships is unreliable? I don't know

I worked with TesTool and I found it enough reliable...but this is only my opinion!!

Regards,
FlyFisherman

[fgs_chuck]

FlyFisherman,

It is my understanding that you only need a valid bootloader running on the SRB if you use a serial port to download the S19 file within Test Tool. Is this incorrect?

If one uses the USB Mulitlink Interface BDM (as I am doing), I don't believe that the bootloader needs to be running on the device because the BDM is supposed to work even if a bootloader is not running on the device. Is this statement incorrect?

Now, having said that, the failing program does indeed have the embedded bootloader compiled into it even though I am using the BDM to download it. Yes, I suspect that something is corrupting memory someplace. However, there is no compilation error.

When the failing program downloads, the download operation produces an error indication and the board fails to do anything after I reset it. If I use the CodeWarrior debugger to download a different program successfully, the board intermittently works after that. I say, intermittently, because some SRB devices will work after this step but others will not.

I used the Test Tool/BDM combination to download the MyStartNetwork demo example that comes pre-compiled on the Freescale CD. One SRB reliably connects each time to the NCB. One SRB connects on some occasions but not others. Two SRBs consistently fail to connect to the NCB. In all cases, I open a hyperterminal session on the USB port of each SRB in order to see the built-in diagnostic messages that the app writes to the serial port. In this way I verified that the program is running on the SRB; it just isn't connecting properly via the RF port.


Regards,
Chuck

[FlyFisherman]

Chuck,

>It is my understanding that you only need a valid bootloader running on the SRB if you use a serial port to >download the S19 file within Test Tool. Is this incorrect?

You are absolutely right.

>If one uses the USB Mulitlink Interface BDM (as I am doing), I don't believe that the bootloader needs to >be running on the device because the BDM is supposed to work even if a bootloader is not running on >the device. Is this statement incorrect?

You are right.

>Now, having said that, the failing program does indeed have the embedded bootloader compiled into it >even though I am using the BDM to download it. Yes, I suspect that something is corrupting memory >someplace. However, there is no compilation error.

But if you compiled the program with the BOOTLOADER_ENABLE (this should be an option of the compiler) you would have to download first the BOOTLOADER with the BDM and after the program through a serial port.

>When the failing program downloads, the download operation produces an error indication and the board >fails to do anything after I reset it. If I use the CodeWarrior debugger to download a different program >successfully, the board intermittently works after that. I say, intermittently, because some SRB devices >will work after this step but others will not.

Which is the error indication?  Intermittently, this is very strange!!!

>I used the Test Tool/BDM combination to download the MyStartNetwork demo example that comes >pre-compiled on the Freescale CD. One SRB reliably connects each time to the NCB. One SRB >connects on some occasions but not others. Two SRBs consistently fail to connect to the NCB. In all >cases, I open a hyperterminal session on the USB port of each SRB in order to see the built-in >diagnostic messages that the app writes to the serial port. In this way I verified that the program is >running on the SRB; it just isn't connecting properly via the RF port.


The behaviour you have just showed is very strange and seems to be random.
But, if also the pre-compiled program failed I think the problem should be on the HW.
Did you test the board with the default programs provided by Freescale?


Regards
FlyFisherman

[fgs_chuck]

FlyFisherman,

I think that I've determined the root cause failure.

The application that initially causes the device to begin failing is a modified Accelerometer template that I generated with BeeKit. I enabled the Embedded Bootloader in the project. This is an SMAC application.

This program has about a dozen long character strings in an included H file. Even though it compiles without error (CodeWarrior v5.1 Special Edition), it must be overwriting some important memory location. If I download the application to the device via Test Tool, close Test Tool, re-open Test Tool, and inspect the NV_RAM structure from the device, I see that the parameters for clocks and various registers are completely corrupted. At this point the device is unusable for anything.

To get it back to a state where it can be used, I need to do the following steps.
1) Compile any small app (that works) and download it via the CodeWarrior debugger and BDM.
2) Close CodeWarrior, open Test Tool, and select the EVK_MyStarNetwork app.
3) Select the NV_RAM Info button. If you inspect the NV_RAM structure from the device, you will see that it still contains corrupted data. So, don't do that. Use the NV_RAM structure built into the MyStarNetwork app and save it to the device.
4) After the NV_RAM structure is saved to the device, it isn't yet permanent. You must continue to download the EVK_MyStartNetwork app to the device. It is now a fully functional device, again.

I spent some time last week with the local Freescale rep looking at this problem. He noticed that ALL SMAC apps generated with BeeKit that contain the embedded bootloader have some problems. With the embedded bootloader enabled, the CodeWarrior Debugger will never work - but only for SMAC templates from BeeKit.

I opened a Freescale Service Report on this issue and have been having an interesting series of responses with them. Their first response was that the BDM doesn't work with Test Tool at all, and, therefore, you are never supposed to use it. After I pointed out that the document "802.15.4/ZigBee Embedded Bootloader Reference Manual" specifically states that you can use the BDM on page 4-1, the response was changed to become, "Well, you just can't use it with any SMAC programs." I then pointed out that I had been using Test Tool and the BDM to download other S19 files that were SMAC templates with the embedded bootloader enabled. I asked for a Freescale document reference of where this limitation is documented, but I haven't heard any response to that request.

Frankly, this sounds like a patient visiting his doctor with the following complaint:
Patient: Doctor, it hurts when I eat.
Doctor: Then don't eat.

Although the original application failure was due to code that I added, I have found that even some of the SMAC demo apps that came with the Freescale CD and have the bootloader enabled in them will corrupt NV_RAM if you download them from the Test Tool. I verified this with the app "accelerometer_v3_13213_SRB_loader". Some portions of NV_RAM became corrupted, but the device was still usable.

The Freescale rep that I was working with last week was pretty convinced that this is an outright software bug in BeeKit. Unfortunately, the Freescale engineer hired to respond to my Service Report seems to be taking a different position. This is frustrating.


Regards,
Chuck