Error Flashing MSP432 Rev 2.0

Antonio,
I do not have the older version and therefore could not recreate. Have you updated the system and startup files, also it may be helpful to delete and re-install the cloud agent.  Let me know if these do not work and I will try to get ahold of the prior versions.

Thanks,
Chris

No, I haven't updated the system and startup files ( as i thought it would be good to go, but i can if you think it is needed, just point me in the direction). I Re-installed the cloud agent, still the same error.

Thanks for the support.

As you suggested i tried two different examples ( PortMap and Serial ), and i looked at the startup files from the Resorce Explorer and form the Cloud CCS, both are in the same version and updated the same date; but for piece of mind i pasted the conde from the startup file from the Resource Explorer in the startup file from Cloud CCS but still get the same error message.

Just for the record, are there any connections that need to be made in the board so that it flashes? I'm using it with all the jumpers that come plugged in the pins, right as the board comes from the box. I'm asking because in the late version of the board there was a JTAG Switch that enable the XDS-ET, that isn't available anymore and i thought that the XDS-ET wasn't been able to communicate with the microcontroller because somehow it is missing some connection to be made (that i have no seen in this document http://www.ti.com/lit/ug/slau597b/slau597b.pdf  wich, by the way, is for REVB and not REVC, REVC is the shipped board from Texas Instruments' Store and this document is from the same page for the board).

Below is a photo of the setup of both boards, black has a JTAG Switch, red don't.

Actually i already tried the factory reset of the microctroller. My CCS appearently performed the reset well, but since it was hanging during the building/flashing i was unnable to really make sure the microcontroller was funcitoning after ther reset, at least in the desktop CCS. Then i made the reset procedure again ( in the desktop app ) but then i decided to flash the device through the cloud application. The first time after the reset, appearently, it flashed the device but it was not performing the program inserted which is a modified version of the Port Mapping exemple from the resorce explorer, the LEDs in P1.0, P2.1 and P2.2 are supposedly to blink but they were not. Then i decided to try flash the device again in the cloud application, but the this time i recieved the same error message.

I also tried to flash the device through the cloud application in my desktop computer in the lab that, but i received the same error message.

I am currently re-installing the desktop application in my personal copmuter so i can perform the identification of the hardware version described in the link you apointed and then i will try again to perform the factory reset.

Thanks.

Well, i re-installed the CCS desktop application ( the i tried to flash a firmware in the board, red version, and again the error massage...then i tried to flash the black version, it worked like a charm!!!) and performed the hardware identification....by the posts on the link you gave it was not at all what i expected, below is a picture of what i found.

So, as you proposed, i performed the factory reset, as described in www.ti.com/lit/ug/slau597b/slau597b.pdf  and the result is shown in the picture below.

Hi Thorsten,

i took the liberty to check the third board we bought, just in case something is wrong with it too. So i unpacked it and went to flash the device, surprisingly it flashed. The program i flashed is comunicating through the eUSCI were i write #two_digit_number and it returns tow_digit_number. The problem is, the firmware was returning #two_digit_number. So i guessed something was wrong, then i went to flash the program again. And gues what, it gave me the same error as the other board. Then i checked the hardware number, it's show in the picture below.

Let me ask you, it is possible that CCS is somehow misreading the TLV_HWREV number or even modifying it?

I ask because is really strange that it flashed the device, even with a firmware that is not behaving correctly ( and for the record i flashed it in the black version and the firmware is behaving correctly ) and then in the secont time the program behaves like the TLV_HWREV is something other than the numbers of the suported versions of the board, so the first time it identified it correctily and then misread/changed it.

Below is a photo of the hardware. But it is the third board (not mine) because i forgot it at home when i came to the lab. But as far as i remember, the labels are the same XMSP432P401R REV C as shown in the pecture below ( if really need for both boards i can take a picture later).

Thanx for the support.

Hi Antonio,

thanks a lot for the picture - that helps us nailing that issue down.
By using eUSCI, does your tool use the boot strap loader (BSL) for programming the device? Then it would be clear why programming is working - the BSL uses the correct routines for programming the device and does not need to check the HWREV.
If you want to program with a debugger we need this information, as there are some differences in flash programming RevC and older HW revisions of the XMS samples.

The TLV data is written during production and is read only - so there is no way to change this. It could be that the data is read out incorrectly by the tools, but I do not believe that.

For the moment, can you live with programming the device via USCI? (Debugging would also be an issue)

If you have the chance could you additionally give as the labeling of the other two devices (at least of the one with the same issue)?

Thanks and regards,

Thorsten

Here the picture of the three boads. The first on the left is the functional one.

*a detail of the third board on the right

the readings on the chip:

flashable: 63AHK2WG4

not flashable: 62ARX1WG4 / 62ARX2WG4

Code Composer Studio

Version: 6.2.0.00050

I'm trying to set up IAR's and KEIL's IDE.

Hi Antonio,

so the same devices which were not working in CCS before, now you could program using Keil? What do you see in the TLV data there for HWREV?

In CCS did you try to create a new Blinky example program from scratch and could you program it? Maybe with re installing CCS?

The free versions of IAR and Keil are size limited - which might be the cause why some of your projects won't work.

Thanks and regards,

Thorsten

Yes i can program, in KEIL's IDE, and the TLV_HWREV shows the correct number, 0x43 for both boards that were not flashing in CCS. But as i said, the same firmware that callibrates the DCO runs in Rev 1.0 but not in Rev 2.0, if i flash a firmware that doesn't callibrate the DCO it run just fine. And the fact that KEIL have limited code size unfortunately is not a valid argument because i flashed both Rev 1.0 and Rev 2.0 with the same code.

Still cannot flash with CCS, as it throws me the same error mesage. CCS was already reinstaled, with a pack that (at the time of the installation) was 3 days old so...

But, it'a really strange that KEIL is reading the correct version of TLV_HWREV, but in those links you send i think one of them was about CCS misreading the TLV_HWREV, i will check it more carefully for some further information.

But it's also really strange the fact that some firmware runs in both Revs and other don't, yesterday when i was playng with it i noteced that when the firmware reached the DCO calibration function instead of executing que code in the function it was jumping through some code that i didn't recognized (something about the startup/system code i guess, it was late at night so i didn't really dit into it) this is why i think is something about the DCO calibration.

P.S.: i get my friend's board, the one that was working.....i flashed a firmware that doesn't calibrate DCO and ok it flashed. Then i proceeded to flash a firmware that does calibrate the DCO and it thrown me the error massage that it was not showing, obviously i panicked and went to flash back the firmware that does not calibrate DCO and nothing....the error massage appeared....i cleaned the project, rebuild and flashed and still get the message. Then i go to KEIL and it flashed fine the program that do not calibrate DCO. Now checking were in the code the program is stuck, the CDO calibration fuction is:

void DCOconfig(void)

I isolated the problem, but didn't find a workaround. The DCO calibration is as given below: