MSP430F5438A Wireless Upgrade

灞波儿奔

MSP430F5438A Wireless Upgrade [Copy link]

The 430 wireless upgrade is to burn a custom BSL program through JTAG, and then receive the application (APP program) through the BSL program.

There are many receiving modes - UART, IIC, SPI. The 430 manual also introduces the BSL protocol and other contents about firmware upgrade.

Due to project requirements, wireless upgrade is adopted. The wireless module is an SPI interface, which can also be understood as an SPI receiving mode.

The BSL program and APP program need to be distinguished in address space and the corresponding XCL files need to be modified.

---- XCL file of APP

Regarding XCL files, since my program is very short, the space is set very small. When upgrading, as long as there is no error when the program is rebuilt, there is no problem.

If there is a problem with the upgrade, you don't need to consider this aspect. You don't need to consider the problem of high address space.

---BSL XCL file

After the address space is allocated, the corresponding program is written. The most critical part of the program is the terminal vector remapping.

----APP program, very simple and convenient for testing

----- About timer interrupt remapping in BSL program

Burn the BSL program, then send the APP program wirelessly and burn it into the corresponding flash space. Finally, jump to the APP area.

Single-step debugging, the program jumps normally. When the global break statement is turned on in the APP program, the program is reset and points to 0xFFFE.

The reset vector contains the starting address of the BSL program, which is 0x7000. However, the program does not execute to 0x7000, but to 0x0000.

If you single-step again, it will jump to 0x0004 and stop.

After observing with an oscilloscope, I found that the clock pin still had a signal, which meant that the program was still running and the interrupt function did not enter. So I kept thinking that it was the interrupt

Vector remapping problem.

Looking at the official website routine again, I found that all useless interrupts were processed. I tried it this way too.

After debugging again, I found that it no longer resets, but enters interrupt 84.

That is, the P2 port interrupt. After checking the IO port configuration function, it was found that the interrupt enable of the P2 port was turned on, resulting in an interrupt, but there was no corresponding interrupt service program.

This problem was finally solved.