MSP430F5529: BSL: Cause of "Memory Verification Error"??

stomp

Genius 4725 points

Part Number: MSP430F5529

Hi,

We are using MSP430F5529 + BSL as a method of assembly line programming and also in-field updates.

In about 1 in every 8 attempts at programming we get a "Memory Verification Error" from the BSL Tool.

The output is below:

Starting
Password Sent Successfully
Sending RAM BSL v00.07.08.38
Done RAM BSL v00.07.08.38
Erasing memory segments 
Sending Firmware.txt
Firmware Sent
Verifying memory
Memory verification error

Can anyone advise what is the cause of this, and why this would occur? And why this leaves our devices in a bricked state.

Thanks.

over 8 years ago

0 Ryan Brown1 over 8 years ago

TI__Guru**** 223557 points

Hi stomp,

The default BSL on the MSP430F5529 communicates through USB and resides in both Bootstrap loader memory (flash 0x1000 to 0x17FF) and RAM (0x2400 to 0x33FF), both areas of which must be programmed with the same version using JTAG communication in order to work properly. Your commands above appear to be programming the RAM BSL section but not the flash BSL. Why are you re-programming the USB BSL at all and without the latest version (00.08.88.39 as of Rev K and later)?

Regards,
Ryan

0 stomp over 8 years ago in reply to Ryan Brown1

Genius 4725 points

Hi,

So maybe there is some misunderstanding with the operation of the BSL application. We simply open the application, provide our firmware .txt file and let it do its thing. I am unsure about BSL version numbers. We simply purchase the MSP430 devices, solder, connect USB, program our application and then test.

Is this not the correct procedure? Should we somehow be re-flashing the BSL 8.88.39 using JTAG first?

Regards
Stomp!

0 stomp over 8 years ago in reply to stomp

Genius 4725 points

Hi,

Just to follow up.

I have updated the firmware.resx in the BSL Tool with the 8.08.39 BSL_RAM file, and I've adjusted the other places in the BSL Tool where the firmware versions is important.

The BSL process works much better now, indeed I am not seeing any of the memory verification problems.

However, new problem:

The BSL process does not reset the target device any-more. Is there something else special that has changed between 7.08.x and 8.08.x that would require some different settings to force a reset after the BSL process. I ask this because in my customer application, power cycling is not an easy thing to do after upgrade.

Thanks
Stomp!.

0 Ryan Brown1 over 8 years ago in reply to stomp

TI__Guru**** 223557 points

Hi Stomp,

It is fine to leave the BSL alone, the issue I notice is that you are sending RAM BSL v00.07.08.38 and I'm not sure why this is. All you should have to do is unlock the BSL with the password and then send the firmware. What software and FET tool are you using to interact with the BSL? You can toggle the RST line to force a reset, the BSL SCRIPTER (SLAU655) also has a SET_PC command that points to the reset vector location in order to restart the application. Caution should be taken however as the BSL program has altered the CPU frequency settings which will need to be re-configured.

Regards,
Ryan

0 stomp over 8 years ago in reply to Ryan Brown1

Genius 4725 points

Hi Ryan,

I've not found some good version numbers but I am using the BSL_USB_GUI built from source code.

Apparently Version is:

1.3.1 04/07/14 A. Bhat  Updated RAM_BSl to v00.07.08.38

The tool works OK, as mentioned previously is fails the memory check randomly.

I've taken this version and applied the 00.08.08.39 RAM_BSL version to the Firmware.resx file, as well as changing some parts in downloadview.cpp to suit the new version. After this modification, the BSL works well, with the exception of resetting the target hardware.

There remains a few questions in Firmware.resx relating the the "Forced_BOR.text" and "Forced_PUC.text" values and their associated addresses. I assume these need to change with the 8.08.39 RAM BSL, but I do not know where to find them.

Do you have any ideas about the locations of BOR or PUC values?

Thanks

Stomp!.

0 Ryan Brown1 over 8 years ago in reply to stomp

TI__Guru**** 223557 points

Hey Stomp,

The addresses and values of the forced BOR or PUC should not change regardless of the BSL version used. Some other change to the source code could be preventing the host application from issuing the BOR command after the firmware has been updated. All that is required for a PMMSWBOR is writing 0xA504 (PMM password plus software brownout reset) to PMMCTL0 @0x120. https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/395535/

Regards,
Ryan

0 stomp over 8 years ago in reply to Ryan Brown1

Genius 4725 points

Thanks Ryan,

I have found some timing issue in the MSP430 BSL tool.

I've modified DownloadView.cpp (about line 386 in my file) to include some additional time delays. Once the delay is added the device resets correctly.

Below is the modded code.

	worker->ReportProgress(90,"Total programming time is " + totalProgramTime + "s \r\n");

	Sleep(1000);
	worker->ReportProgress(91, "");
	Sleep(1000);
	worker->ReportProgress(92, "");
	Sleep(1000);

	// Force a BOR
	TriggerForcedBOR(worker, e);

	worker->ReportProgress(100,"Done!");
	e->Result = true;

Thanks

Stomp!.

0 stomp over 8 years ago in reply to Ryan Brown1

Genius 4725 points

Hi Ryan,

I spoke too early.

By putting the delay before the BSL issues the reset works, however we still randomly get (both at our office and customer site) the memory verification error from the BSL tool.

Can you assist with what is the cause of the verification error? How do we debug this?

Thanks.

0 Ryan Brown1 over 8 years ago in reply to stomp

TI__Guru**** 223557 points

Hi Stomp,

Are you able to use a JTAG connection to read out the programmed memory of a failed device and compare that with successful runs or expected memory contents? I assume these devices can be recovered and then programmed correctly? Have you consider using the BSL-SCRIPTER tool since its firmware is updated more regularly than the referenced app note resources?

Regards,
Ryan

0 stomp over 8 years ago in reply to Ryan Brown1

Genius 4725 points

Hi Ryan,

I can connect to the device that fails programming, I can download and compare device memories and there are significant differences at various addresses, in particular towards the end of the device.

If it is any help, I also stepped through the BSL tool's Check_CRC function (The memory verification) and I find that memory verification fails when requesting a CRC from addx 0x17532 onwards with length 0x1198. My application has code from 0x4400 to 0x186C8.

The function at 0x186C8 is only 2 bytes and 0x17532 + 0x1198 = 0x186C8 + 2, so I'm happy with the length, just not happy that the CRC is failing.

Again, this problem is very random in nature, currently about 30% failure rates, but those 30% result in bricked boards.

I will look at the scripter tool, but I thought BSL was a well tested and stable system?

Thanks.

0 Ryan Brown1 over 8 years ago in reply to stomp

TI__Guru**** 223557 points

Hi Stomp,

The BSL peripheral is a well tested and stable system but the software programmer involved could be having trouble with large memory addresses (> 0xFFFF). It appears that a timing issue is involved with differences at the end of device memory, this is why I would like to know what happens if the scripter tool is used instead.

Regards,
Ryan

0 stomp over 8 years ago in reply to stomp

Genius 4725 points

Hi Ryan,

I know this thread is slightly old, but I'll just close off our findings.

We ended up re-writing the MSP430 BSL Windows tool in .NET and found a few notable things occurring:

1. Every now and then a HID report would fail with a timeout. I guess the BSL tool could not determine if this failure happened, especially in fast write mode.

2. We continued to get memory errors, but only when our program grew in size. The reason we think we saw errors above 0x18000 was because the sections of memory were not being erased correctly, and therefore failing the CRC checks. We added some extra code at in the BSL tool once erasing the flash sectors to erase another 512 bytes after the last memory address. This seems to have totally eliminated the problem and my guess there was some page size limitation when erasing? (i.e. our program size was larger than the memory erase size).

3. We also added a small delay after the last flash erase, before the programming starts, unsure if this has made any improvements or not.

We did not get to try with the BSL scripter tool as it was deemed too hard to fit it into our work flow.

Thanks.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430F5529: BSL: Cause of "Memory Verification Error"??