Hello Everyone,
I wonder if someone ever faced this problem: I built a new PCB
using the MSP430F2132, based on a older (functional) project. Very
simple circuit and standard JTAG interface.
On the new boards, when I try to flash the software, for example
using MSP430Flasher and MSP-GET430UIF, I get this error:
msp430flasher -n msp430f2132 -w mainkernel.hex -v
Evaluating additional triggers...done
Initializing interface on USB port...done
Checking firmware compatibility...done
Reading FW version...done
Reading HW version...done
Powering up...done
Configuring...done
Accessing device...done
Reading device information...done
Loading file into device...
* * ERROR : Verification error*
Unable to load file.
Resetting device...done
Refreshing registers...
/*
----
* UseCase : msp430flasher
* Arguments : -n MSP430F2132 -w mainkernel.hex -v
*
----
0,0,0,0,0,0,0,-1,0
* ERROR : No error
# Exit: 11
# ERROR 1014: No error
* Disconnecting from device...
*
----
* Driver : closed (No error)
*
----
*/
In NoIce430, it connects to the boards, identify the MSP and stops
flashing right at the first page (0x1000), also returning verification
error.
The weird part is the device does actually flash (using
MSP430Flasher). I am not sure if it is 100% ok, but it enough to bootup
the software.
I already build three PCBs, but all returns the same error. The
last one I just placed the MSP few required cap and resistors. Same
problem persists. I even used a MSP from another batch, just to make
sure... same problem over and over.
Anyone? Any insights would be very welcome.
Calin
Strange MSP430F2132 flashing behavior - Verification error
Started by ●October 26, 2012
Reply by ●October 26, 20122012-10-26
One of the possibilities is the way F2132 gets Vcc supplied. When you start to
erase or write to Flash. The chip draws a lot more current. If this causes Vcc
to dip down, you might get the observed problems.
Reply by ●October 26, 20122012-10-26
On one of our 1611 designs, the engineers put a large cap on the reset line to
debounce the manual reset switch. The cap was messing up the JTAG init sequence
until a much smaller cap was substituted. Are you powering the UIF from the
board or from the USB? There is an additional voltage that the UIF needs if
powered from the board but should not go to the UIF if powered from USB.
Reply by ●October 26, 20122012-10-26
Reply by ●October 27, 20122012-10-27
Hello everyone,
I found the cause of the problem, but it is a really strange. I
notice NoIce returns verification error on page 0x1000 (information
area), so I focused my attention to this flash area.
In my software I use the available 256 bytes of MSP4302132
information area to save a CRC8_Table. Something like that:
#pragma abs_address 0x1000
const unsigned char CRC8_TABLE[256] = { .... 256 bytes listed ...};
#pragma end_abs_address
It always worked fine (over 50 old PCBs working with this code).
Just as a test, I started reducing the amount of bytes declared on
this area. For my surprise I found out that when I reduce the array to
192 bytes it flashes ok. No errors at all.
I tried 3 different programmers I have here, on a couple different
computers. Same result on every test.
Does anyone have any idea why the information area does could not
fit 256 bytes anymore? To add a little more to this weirdness, the same
device (same batch) flashes ok on another board.... how could this be
possible?
Thanks everyone for the tips.
Calin
I found the cause of the problem, but it is a really strange. I
notice NoIce returns verification error on page 0x1000 (information
area), so I focused my attention to this flash area.
In my software I use the available 256 bytes of MSP4302132
information area to save a CRC8_Table. Something like that:
#pragma abs_address 0x1000
const unsigned char CRC8_TABLE[256] = { .... 256 bytes listed ...};
#pragma end_abs_address
It always worked fine (over 50 old PCBs working with this code).
Just as a test, I started reducing the amount of bytes declared on
this area. For my surprise I found out that when I reduce the array to
192 bytes it flashes ok. No errors at all.
I tried 3 different programmers I have here, on a couple different
computers. Same result on every test.
Does anyone have any idea why the information area does could not
fit 256 bytes anymore? To add a little more to this weirdness, the same
device (same batch) flashes ok on another board.... how could this be
possible?
Thanks everyone for the tips.
Calin
Reply by ●October 27, 20122012-10-27
Trty looking at the setup under programming options. On the IAR tools
under PROJECT-OPTIONS-FET DEBUGGER-DOWNLOADS you have the ability to
select which memory sectors are erased and reprogrammed. Under newer
vewrsions INFOA is locked as this contains various calibration data. You
need to specifically unlock this.
Al
under PROJECT-OPTIONS-FET DEBUGGER-DOWNLOADS you have the ability to
select which memory sectors are erased and reprogrammed. Under newer
vewrsions INFOA is locked as this contains various calibration data. You
need to specifically unlock this.
Al
Reply by ●October 29, 20122012-10-29
Gabriel,
I don't know about the msp430Flasher, but I am using a bootstrap loader based on an old TI design and have discovered an anomaly
When using it to download hex files to msp430. I have no idea if this is causing your problem, but since you can find out in under 5 minutes,
Here goes:
Our downloads fail during the writing phase IF the hex file has an odd number of bytes in any section. I know I should have fixed this bug by now
But instead I edit all of my release hex files and add byte "FF" to make the number of bytes even. Maybe someone can point out how to fix this bug.
For example, if the file contains
@1030
01 04 44 56 0D
I change it to
01 04 44 56 0D FF
And all is well.
Like I said, check your file to see if you have this problem. It is possible your device is based on the same (buggy) code.
Good Luck
Mike Raines
I don't know about the msp430Flasher, but I am using a bootstrap loader based on an old TI design and have discovered an anomaly
When using it to download hex files to msp430. I have no idea if this is causing your problem, but since you can find out in under 5 minutes,
Here goes:
Our downloads fail during the writing phase IF the hex file has an odd number of bytes in any section. I know I should have fixed this bug by now
But instead I edit all of my release hex files and add byte "FF" to make the number of bytes even. Maybe someone can point out how to fix this bug.
For example, if the file contains
@1030
01 04 44 56 0D
I change it to
01 04 44 56 0D FF
And all is well.
Like I said, check your file to see if you have this problem. It is possible your device is based on the same (buggy) code.
Good Luck
Mike Raines
Reply by ●October 29, 20122012-10-29
