MSP430FR2475: INTR Vectoring

Ian Scott

Part Number: MSP430FR2475
Other Parts Discussed in Thread: MSP430FR2476,

we are writing our own bootloader, to make sure we have control over the device. We are running into a problem and wonder if you could look at the following;

After power up the bootloader is executed.

Its interrupt vector is copied from FRAM (0xFF80 – 0xFFFF ) to top of RAM ( 0x2F80 – 0x2FFF )

The Stack pointer will start at 0x2F7F, so it does not interfere with the RAM int vect.

After that we relocate the interrupt vector to ram by setting:

/* use the ram interupt vector */

SYSCTL |= SYSRIVECT;

Now the only interrupt that has been enabled is the UART interrupt.

Our problem is, as soon as the interrupt fires (we receive a byte), the program goes into the woods and resets due to the watchdog.

If we do not relocate to RAM VECT, the program works fine, but we still have same problem when the application is loaded and it changes its interrupt vector to top of RAM.

Now here is the funny thing:

If we use the development board (with the MSP430FR2476 chip), and relocate the interrupt vector to top of RAM ( 0x3F80 – 0x3FFF ), it works fine! The stack pointer still works from 0x2F7F.

For this design the bootloader works perfect, and the application loads and executed correctly.

Is there an anomaly in the MSP430FR2475 or does is the RAM interrupt vector located at another spot?

over 2 years ago

0 Jace H over 2 years ago

TI__Guru 56685 points

Hello Ian,

Yes, the MSP430FR2475 has less RAM than the MSP430FR2476. Check out the Table 6-31. Memory Organization in the device datasheet to see this comparison and to get your start address of RAM for MSP430FR2475. So you may have to adjust some of the redirects in your code to be compliant .

Now for your custom bootloader, are you starting from MSPFRBOOT? MSPFRBOOT APP Note As our solution takes care of the bootloader and application switching for you. This could save you a lot of time if you are trying to do it form scratch as you would only need to customize this. You don't necessarily have to do it in RAM either, you could redirect to a different section of FRAM as well.

0 Ian Scott over 2 years ago in reply to Jace H

Prodigy 10 points

Thanks for the answer.

We have made a workaround where we use the method used for MSP430s that do not have a bit that can relocate the interrupt vector to top of RAM.

As mentioned we can relocate the vector for MSP430FR2476, when we

Read the DEVICE_ID to verify we do run on a MSP430FR2476
Use the top of RAM that is 0x3FFF for the interrupt vector ( copy 0xFF80-0xFFFF to 0x3F80-0x3FFF)
Set the stack pointer to 0x2F7F, verified when we start the debugger.
Set the SYSCTL |= SYSRIVECT

If we do this on a MSP430FR2475 and do this:

Read the DEVICE_ID to verify we do run on a MSP430FR2475
Use the top of RAM that is 0x2FFF for the interrupt vector ( copy 0xFF80-0xFFFF to 0x2F80-0x2FFF)
Set the stack pointer to 0x2F7F, verified when we start the debugger.
Set the SYSCTL |= SYSRIVECT

The program hits an illegal address, when an interrupt happens.

So the question is why?

I can see two possible reasons:

The MSP430FR2475 does not support relocation of the interrupt vector
The MSP430FR2475 has its RAM interrupt vector placed at another location

Off course there may be others, but can anybody verify that it should work?

0 Jace H over 2 years ago in reply to Ian Scott

TI__Guru 56685 points

Hello Ian,

I'm glad you where able to find a workaround int he time being.

It should be feasible. I'm unsure of what is going wrong here. This is not a common use case so it will take some time to dig into. Do you have an example project you can share with minimal amount of code that demonstrates the issue? This would help speed up debug tremendously.

In the mean time, I'll do some research on my side, but it will be the end of the week before I can get back to you.

0 Jace H over 2 years ago in reply to Jace H

TI__Guru 56685 points

Ian,

I haven't had much luck in my investigation so far. I did find the following that is on a different device family, but some of the same principles may apply. Although this device is not dealing with a RAM boundary such as the exact situation linked, there is some merit around making sure the linker file excludes that part of RAM. Let me know if this helps.

0 Ian Scott over 2 years ago in reply to Jace H

Prodigy 10 points

Thanks again for your assistance, it is much appreciated.

Yes we are aware we need to change the linker descriptor file.

We have made the following modifications to the MSP430FR2475.xcl file, to be sure the stack pointer starts at the right space

// -----------------------------------------------

// RAM memory

-Z(DATA)TINYRAM=0006-001F

-Z(DATA)DATA16_I,DATA16_Z,DATA16_N,TLS16_I=2000-2F7F

-Z(DATA)CODE_I

-Z(DATA)DATA20_I,DATA20_Z,DATA20_N

-Z(DATA)CSTACK+_STACK_SIZE#

Runtime we copy the app int vector (which we have placed at FFA2-FFFF) to (2FA2-2FFF). We have verified this copy is correct.

Then we set the relocation bit.

We have also verified 2FA2-2FFF is not corrupted after the program has gone into the woods. The Stack pointer has not touched this area.

If we do exactly the same on a MSP4302476 process, BUT changes the runtime copy to 3FA2-3FFF, it runs smoothly. Notice we use the same linker descriptor file, meaning the stackpointer is still starts at 2F7F

0 Jace H over 2 years ago in reply to Ian Scott

TI__Guru 56685 points

Interesting. Can you perform a quick test? Can you use the MSP430FR2476 project that works, but compile for FR2475 without changing to FR2475 RAM bounds? This should fail as its outside RAM bounds, but if it doesn't, it would give another data point to the issue.

Are you comfortable sharing a version of your project here?