ChipKits Executing code differently

Created Wed, 12 Jun 2013 04:11:01 +0000 by Bryce1111

Bryce1111

Wed, 12 Jun 2013 04:11:01 +0000

Hello,

  I am currently making a large LED Cube and I am using four chipKit uC32's to control the animations. I have written a large amount of code so far and have tested it on one of the boards I have and everything runs as it is supposed to. Well, I decided to test this code on one of the other three boards I have and it displayed a pretty erratic animation on the LED cube. It was the same program from the first one (which worked), but not it was not working like it was supposed to. Well, this SAME exact behavior happened on the next two chipKit boards and I have no clue why. When I went back to the first board (thinking it was a programming issue that I missed) I re-uploaded the SAME program which had not worked on the previous three boards and the program worked perfectly. So I would assume that, because the program worked as I had written it, then its not a programming issue and not a hardware  issue on my side, which leaves me to assume that these (three?) boards are not working properly. The only different between the four boards is that the board that works has a sticker on the bottom which I would certainly assume is related to quality control. The board that works says "Q.C OK 2" and the boards that are not working say "Q.C OK 1." 

 Anyways, what I wanted to know is what you think. I was hoping that re-bootloading the boards would fix my problem. Then only issue is that it is taking me a while to figure out how to properly do this. I have been trying to use the USBTinyISP programmer to do it, but I think I have just found out that you can't bootload the PIC32 with it. is this correct and would re-bootloading fix my problems? I would like to find out before I devote too much more time trying to figure out how to bootload it and then find out that it has not been the issue the entire time. 


Thank you!

EmbeddedMan

Wed, 12 Jun 2013 12:43:47 +0000

Bryce,

I'm pretty certain that re-programming the bootloader would not solve your problems. Except in some strange cases, the bootloader won't really have an effect on how your application code runs.

There must be some other difference between the one that works and the three that don't. Can you put some simple programs on the ones that don't (like blinking LED, then basic testing out of your hardware, etc.) to try and see what exactly the difference is? Are all of the jumpers set exactly the same between all four boards? If you had some programs you could run that would test out one part of your interface to the LED cube at a time, you might be able to narrow down what it is that isn't working - like a pin that's not outputting anything when it should, or messed up timing on a pin, etc. Any clue as to what is actually different between the behavior of the boards will help us help you figure out what the root cause is.

*Brian

majenko

Wed, 12 Jun 2013 12:49:41 +0000

Question: Does the bootloader do a full-chip erase, or an on-demand page erase?

If the latter then it could be a programming error that's causing the problems, and old data left over in flash from earlier iterations that hasn't been erased could be helping the bug to stay hidden on the one board, but the "fresh" boards, without that old code lying around, wouldn't work right.

Of course, this is pure supposition, but it could be good to check through your code looking at things like array bounds, etc - remember, arrays are zero based, so an array[5] has slices 0, 1, 2, 3 and 4, as does an array[] = {3, 42, 3, 94, 12};

EmbeddedMan

Wed, 12 Jun 2013 16:47:26 +0000

The bootloader only erases the block that is about to be programmed, I believe. It can't do a full chip erase, as that would erase the bootloader as well.

*Brian

majenko

Wed, 12 Jun 2013 17:13:02 +0000

The bootloader only erases the block that is about to be programmed, I believe. It can't do a full chip erase, as that would erase the bootloader as well. *Brian

Isn't the bootloader flash separate from the main flash? ("32K to 512K Flash memory (plus an additional 12 KB of boot Flash)") The HID bootloader I use does a full chip erase by iterating through all the flash blocks of the main flash area erasing them.

EmbeddedMan

Wed, 12 Jun 2013 22:38:31 +0000

Correct - but "full chip erase" is actually an ICSP command that, well, erases the entire chip. All config bits, all Flash areas. Everything. Wipes every last bit clean. So, from that perspective, neither your HID bootloader nor the chipKIT bootloader do a 'full chip erase'.

I think there are only two ways to erase any given section of Flash on a PIC32. Either the full chip erase, or just a block at a time. What I was referring to was that our bootloaders erase a block at a time.

I think what you're getting at is if they erase all of the available (i.e. non-bootloader used) blocks at once, or just one at a time as they are needed, correct?

*Brian

majenko

Wed, 12 Jun 2013 23:02:05 +0000

Correct - but "full chip erase" is actually an ICSP command that, well, erases the entire chip. All config bits, all Flash areas. Everything. Wipes every last bit clean. So, from that perspective, neither your HID bootloader nor the chipKIT bootloader do a 'full chip erase'. I think there are only two ways to erase any given section of Flash on a PIC32. Either the full chip erase, or just a block at a time. What I was referring to was that our bootloaders erase a block at a time. I think what you're getting at is if they erase all of the available (i.e. non-bootloader used) blocks at once, or just one at a time as they are needed, correct? *Brian

Yes, that is correct. And I know that there is an ICSP command for "full chip erase", but we're talking bootloaders, not ICSP, so I would have thought the "obviously not including the bootloader flash, which is where the code to do the erase is running from" would go without saying.