MSPM0G1506: Application update fails using UART BSL

Hi Fabian,

I have not seen this issue previously, have you tried utilizing the Uniflash tool as your BSL host to see if this flash programming succeeds for all memory locations?

I do not see any issue with the memory locations you are using. As for your program size, the tool should support programs that span the entirety of the devices flash, so one extending up to 0x6400 should not be an issue. 

Could you try with another BSL host like Uniflash mentioned above and let me know the results? This will tell us if the issue is in the BSL GUI tool.

Additionally just to clarify, you are interfacing the BSL GUI with the LP-MSPM0G3507, correct?

Hi Dylan,

Thanks for your reply! Yes, I use the BSL GUI with the LP-MSPM0G3507 to flash a MSPM0G1506 controller as target.

I must admit that host and target are not connected directly over UART. Instead we have a LIN transceiver on each end to transmit data via LIN. Therefore we had to implement a filter on the MSPM0G3507 on the EvalBoard which cuts off the echo from the LIN transceiver.

This is the concept:

How can I use this Uniflash with the same setup? I tried the following configuration but that didn't work:

Before the update I erased the target via debugger. So the controller should enter BSL after power cycle and use default UART pins PA10/PA11.

What am I doing wrong?

Best regards,

Fabian

Thank you for the information here. I see your setup diagram and this is helpful, but I am a little unclear on your implementation. If the LP-MSPM0G3507 is behaving as the BSL host that is transmitting the program data to the MSPM0G1506, that should be fine. But if this was the case, I do not see the need for the BSL GUI to be running on your PC. Are you using the BSL GUI to flash the LP-MSPM0G3507 with another BSL host program, then using the LP to flash the MSPM0G1506? 

I am just missing why the GUI is needed when you have the LP functioning as the BSL host. Maybe if you could tell me what software is running on the LP to explain? Are you using an example?

My expectation with the BSL GUI is that you connect the PC to the launchpad, and in that case the launchpad is the BSL target device. Then by programming with the GUI, you are flashing the LP. The GUI isn't working with the assumption that the Launchpad is then connected to a target device.
Sorry to keep returning with questions, I am just a bit confused at the steps you are taking and what your intended behavior is. In my view it currently looks like you have 2 BSL hosts and 1 target.

Ah, maybe my explanation was a bit confusing. Sorry for that! I try it again: 

My PC (running the GUI) is the BSL host to flash the MSPM0G1506 on the target PCB.

On the MSPM0G3507 of the LP runs an application that I flashed via debugger. This application forwards the data on the UART RX/TX and cuts off the echo from the LIN transceiver. It is necessary because the echo was interpreted as an invalid answer by the host. So, I would say the LP is not a 2nd BSL host but rather a helper and gateway for the BSL host on the PC.

I hope, this helps ypu to understand my setup. If not, let me know. Or maybe you have a suggestion how to it better.

This setup works fine, but as I described in the original post: The update fails sometimes because the firmware is not written completely.

Oh I understand now, thank you for clarifying.

I would think that you could use the Uniflash tool in the same way, since your LP is just forwarding the data to the target device. Maybe the responses from the target are not getting back to the Uniflash tool, causing that error.

Anyways, my concern here would be whether the LP is forwarding all of the correct data, have you tried probing the UART between the LP and the target, and making sure that the data matches the data between the PC and the LP? This could tell us if the error comes from the LP or the GUI.

I'd also like to ask if you have tried using an alternative implementation - you could wire the XDS110 UART on the Launchpad directly to the target device, bypassing the MSPM0G3507 on the Launchpad. Then the BSL GUI is communicating directly with the target device. This would result in a simpler system with fewer points of potential failure. Have you tried this / is this a possibility? I would highly recommend using this simpler set-up if possible.

Thanks for posting your resolution to the issue here, Fabian.

As for padding your image to align correctly - what tools are you using to build the image that you are flashing? The default settings for examples imported from our SDK to CCS, IAR, Keil, should already be configured for 8 byte alignment.

I use Keil to build the hex file. For conversion to txt file, which is required as input for the BSL GUI, I use srec_cat with the following command:

srec_cat.exe %inputFile% -intel -fill 0xff -within %inputFile% -intel -range-padding 8 -o %outputFile% -TI-TXT

Executing this command generates an 8-byte aligned image in TI-TXT format.

Where can I configure the alignment in Keil? I haven't found an option in the Keil project settings.

This would be specified in your Keil Scatter file. It looks like you can just use the:

ALIGN 8 

Operand inside of your scatter file to specify 8 byte alignment.