Bricked black Jaguar after bad firmware update

[FRC4ME]

Okay, so today we were really excited to finally get the CAN working and began the process of flashing all of our Jaguars. We're using a black Jaguar as a bridge between a PC serial port and the CAN interface.

Everything was going well, until I accidentally flashed the grey firmware onto the black Jaguar (I was assigning a new ID to a grey one further down the line, then ran the firmware update without realizing the active board resets to the lowest ID (the black Jag in our case) after an assignment). After this, the LED doesn't light up and the black Jag won't respond to any commands.

The real problem is, we have tried all of the common solutions to this problem. We tried downloading the correct firmware from the bdc-comm command line utility. We tried downloading to ID 2 (what we had last set it to) and ID 1 (the default); neither work. The download appears to progress but takes forever (about an hour), and after it reaches 100%, the Jaguar still has no light and does nothing.

We also tried using the bdc-comm boot command, which is supposed to send firmware to a Jaguar if you boot it while holding down "the button" (I assume this means the user button). When we do this, bdc-comm seems to respond; a huge amount of "." characters suddenly fill the command line window. But no download starts and nothing happens to the Jaguar.

Is there anything else we can try? I don't understand why the normal solutions to this problem aren't working for us. Is there a way to broadcast firmware (send to ID 0)? Any way to reset the Jaguar to factory defaults?

Thanks for any assistance

[dyanoshak]

There is a new version of BDC-COMM that should help with your problem. See this thread for instructions.

-David

[FRC4ME]

Originally Posted by dyanoshak

There is a new version of BDC-COMM that should help with your problem. See this thread for instructions.

-David

Thanks for the tip. Unfortunately, not even this procedure can manage to fix our Jag. We get an "unable to contact bootloader" error. At this point I think we must have done something while troubleshooting the problem that managed to get the Jaguar into even worse of a state than bad firmware.

What's everyone's experience with the Jaguar RMA process? We've filed an RMA but want to get things moving as soon as possible. If we don't get a response from TI very soon we'll just buy another Jag.

[_Tanto_]

ya we had the same problem with two of ours
this link should help you out http://www.chiefdelphi.com/forums/sh...ount=5::ouch::

[simpsonboy77]

Originally Posted by FRC4ME

(I was assigning a new ID to a grey one further down the line, then ran the firmware update without realizing the active board resets to the lowest ID (the black Jag in our case) after an assignment).

Could you elaborate on this? Is it black jaguar specific? We are using the 2can to connect the CAN bus to the cRio instead of the black jaguar. I am mostly hung up on what you mean by "active board".

Thanks in advance

[FRC4ME]

Originally Posted by simpsonboy77

Could you elaborate on this? Is it black jaguar specific? We are using the 2can to connect the CAN bus to the cRio instead of the black jaguar. I am mostly hung up on what you mean by "active board".

Thanks in advance

Don't know much about 2CAN, but when using BDC-COMM, the utility will poll the CAN bus to see what devices are connected. Each device has a unique ID. You must choose an ID before sending commands; the commands you send will go to the device with that ID (what I called the "active board").

When you assign a new ID to a device, the utility re-polls the CAN bus for devices (since one of the IDs probably just changed) and lists their IDs again. It automatically selects the lowest ID as the active device. In our case, this happened to be the black Jaguar.

The scene went something like this:

1. We are flashing our grey Jaguars by connecting them one at a time to the black one.
2. We plug in the next grey Jag and select its ID (1 by default) in BDC-COMM.
3. We assign an ID of 5 to the grey Jag.
4. We realize, "oh, crap; we forgot to update the firmware."
5. We quickly click "update firmware," not realizing the active ID has reset to 2 (the black Jag).
6. In our attempts to get the black Jaguar working again, and before hearing about the proper recovery procedure, (I presume) we do something that messes it up even more.

So yeah, our Jag is still dead and TI's tech support isn't being very quick: yesterday was the third day in a row I got an, "I've forwarded this to the correct team; you should hear from us shortly" email and didn't hear from them for the rest of the day. So I just went ahead and ordered another black Jag from Digikey.

[simpsonboy77]

I spoke with Omar Zrien, and he explained how the CAN flashing protocol works. The jaguars have 2 types of execution code, the firmware and the bootloader. When you select the firmware and an address, the 2can device first broadcasts a message which says "whatever device has an ID of the number chosen, go to the bootloader." Then it will broadcast to everyone on the bus in bootloader to start accepting the firmware.

I assume that the can protocol is the same regardless on what the gateway is between the can bus, and the cRio. The BDC-comm utility might combine these steps into 1, so it appears as though it is 1 operation to the programmer. Again, I don't know much about the black jaguar,so most of this paragraph is speculation.

Thanks for your explaination, I understand you now.

[Mr-Shutter]

The CAN bootloader is in the first part of the flash memory on the MCU. When you flash it, it overwrites the bootloader and the program. The only way to fix this is to use a JTAG programmer. The JTAG headers are found inside the jaguar.

There is no longer a CAN/Serial bootloader on the device. If you would like, I have some Luminary Micro Development boards, I believe I can re-flash your device.

[Mike Copioli]

Originally Posted by Mr-Shutter

The CAN bootloader is in the first part of the flash memory on the MCU. When you flash it, it overwrites the bootloader and the program. The only way to fix this is to use a JTAG programmer. The JTAG headers are found inside the jaguar.

There is no longer a CAN/Serial bootloader on the device. If you would like, I have some Luminary Micro Development boards, I believe I can re-flash your device.

This is not how the boot loader is implemented on the Jaguar. The boot loader is stored in a protected block of flash not RAM. It is a separate section of blocked off program memory that can only be overwritten when using the JTAG interface. Boot loading over CAN cannot overwrite this area of Flash. The driver station from 2009 had a boot loader that operated as you described. The Jaguar boot loader is more robust. The only issue is that when the Jag is in boot loader there is no LED status to indicate as such so the Jag appears to be "bricked" when in fact is just stuck in boot loader.

[Mr-Shutter]

I withdraw this post to prevent misinformation

Thanks Mike

[Mike Copioli]

I think you will find the boot loader is still present as we have discovered on all of the "bricked" Jaguars that we have seen. It is in fact most likely just stuck in boot loader. Now this does not mean there is not a bug in the boot loader that is causing this behavior. This could be the result of some race condition or problem with the CAN layer of the boot loader. I have removed power in the middle of a re-flash several times without ever "bricking" a Jag. If your interpretation of the boot loader is correct this would definitely brick the Jag but it does not. Why do you think the block of RAM that the Bootloader is stored in is not protected? Is it because of the prompt in the bdc comm utility? The BDC comm could be giving you this warning because it is about to overwrite the boot loader. If this is the case a power cycle while updating the boot loader will absolutely brick the Jag. BTW "protection" simply means that the application cannot overwrite the block that the boot loader is contained in. It is still possible to access this block of memory from the boot loader its self.

[dyanoshak]

Hi all,

So far I have been unable to recreate the situation where a Jaguar gets corrupt and cannot be recovered.

Could you please post the steps that you were taking when the Jaguar would no longer accept an update?

An example of one of my successful (unsuccessful in recreating the problem) tries:

Using bdc-comm-88.exe in the GUI, one Black Jaguar connected through serial port on computer (not a usb-serial adapter).

1. Updated with Jaguar-87.bin (on purpose).
4. Update progress bar finished with no errors, but Black Jag is in LED off state.
2. Did not cycle power, tried Recover Device option (Update was grayed because there were no other Jags on the bus) with BlackJaguar-87.bin. 3.Progress bar completed and the Black Jag came back on line.

Be quite specific on what you do; when do you power-cycle the Jag, what does bdc-comm show, were you using 2CAN instead of bdc-comm, etc. Anything, no matter how insignificant, might give me some insight to what is going on.

If you could also answer these questions:

-Are you using a true serial port on your computer or are you using a usb-to-serial adapter?

-Have you "bricked" (by firmware issues) only Black Jags, Gray Jags, or both?

-Are they the only Jaguar connected when this happens?

-When updating firmware, is your 6p6c modular cable (from serial adapter to first Black Jag) running through the robot, is it isolated, long, short, etc?

I have noticed that sometimes when you get a "Cannot contact the boot loader!" error, disconnecting and reconnecting in BDC-COMM and reattempting the recover will work.

I will update with more once we can pinpoint what is going on.

-David

[Mr-Shutter]

Try Uploading the firmware on a bdc24 with bdc88 firmware and then hit cancel immediately when you realized what you just did was a horrible idea.

I have noticed that sometimes when you get a "Cannot contact the boot loader!" error, disconnecting and reconnecting in BDC-COMM and reattempting the recover will work.

GOLDEN, Thanks :3

[dyanoshak]

I tried this just now; It caused my bdc-comm to not respond and quit. After re-opening my bdc-comm I was able to use Recover.

Did you see a similar result (besides not being able to recover)?

Could you please answer some of the questions from above?

Thanks for your help! Every little bit counts when you're trying to reproduce failure modes when there are so many variables.

-David