MSP430F6736: Difference in behavior when writing .out files to devices that differ only in memory capacity

O.H said:

Currently, We are trying to create an executable file by creating a new project in the proper way, setting the device information as F6736, and keeping the linker and other settings the same.

This would be the recommended method to avoid any issues.

O.H said:

The difference from the expected behavior is that it is not accepting the startup trigger by UART reception. (UART interrupt is not accepted)

The interrupts addresses are all the same in the linker files, so I'm not sure what would cause this. If they're using DMA with UART, the issue could be caused by DMA9. Again, I'm not sure why that would happen on F6736 and not F6733. What do you mean by "UART is not accepted"? Is the RXIFG set? Are they checking this using a debug session or with the code free running?

O.H said:

The exact information and detailed diffs are currently under confirmation, but I am concerned that I may have missed some fundamental factor. I'm sorry for the lack of information, but I would appreciate it if you could tell me what you think might be the cause.

Perhaps you can try changing the F6733 project settings to use "small model" for code and data memory, but if you're going to do that, I would just recommend changing the project settings from F6736 to F6733 and move on.

Hi,

Sorry for the late reply. Thank you for your answer.

James Evans said:

This would be the recommended method to avoid any issues.

By eliminating the differences in the linker command file, I was able to confirm that it works with F6736, although I am not sure if it works exactly the same. However, in this case, it is determined that there is a change in the F/W, so the final product will need time to be verified. The reason behind this replacement is that the device cannot be delivered. Therefore, they want to avoid the period of time to verify by using the same .out file if possible. (Or write the .hex file from UNIFLASH...?)

James Evans said:

The interrupts addresses are all the same in the linker files, so I'm not sure what would cause this. If they're using DMA with UART, the issue could be caused by DMA9. Again, I'm not sure why that would happen on F6736 and not F6733. What do you mean by "UART is not accepted"? Is the RXIFG set? Are they checking this using a debug session or with the code free running?

The combination of UART and DMA will be under confirmation. However, since the original F6733 does not have the problem, we believe that it is not being used or that countermeasures are being taken.

As for the behavior of not accepting UART interrupts, they were not able to debug it properly because it was returning to the beginning of the main() function every time. So we are asking them to monitor the reset flag (SYSRSTIV) to see if any unintended resets are occurring.

Q:Are areas that are not defined in the linker command file automatically filled with "FF"?

Since the same .out file is written to both F6733 and F6736, but the behavior is different, we think that the memory area in F6736 may be causing the problem. I will actually check it out, but please let me check how the compiler works.

James Evans said:

Perhaps you can try changing the F6733 project settings to use "small model" for code and data memory, but if you're going to do that, I would just recommend changing the project settings from F6736 to F6733 and move on.

For the above reasons, it is best not to make any changes to the project, but I will check and see as part of my investigation into the root cause.

Best regards,
O.H

O.H said:

Q:Are areas that are not defined in the linker command file automatically filled with "FF"?

The Flash memory is "filled with FF" because it is erased before it gets programmed. After programming, the unused memory shows up as "FF".

It sounds like you've given the customer several things to check. Let us know what they find out.

Hi James Evans,

We worked with a customer to debug a board with the F6736 on it. The details are described below.

Replace the F6733 on the board with the F6736 and implement the firmware originally used for the F6733.

1. It was confirmed that the data was received because the receive interrupt flag (RXIFG) was set when receiving UART data.
2. The program counter (PC) jumps to an unintended area (0x6xxxx) and seems to be stuck though it should enter the interrupt processing of UART.
3. Since the interrupt processing of UART is not done, the reset is repeated by WDT periodically.
   However, SYSRSTIV was showing 0x02 (BOR).

If the firmware content (linker command file) is changed for F6736, it works. So we expect no hardware problems.

After checking the .cmd and .map files, we found that "Alternate Interrupt Vectors" were being used.
MSP430x5xx and MSP430x6xx Family User's Guide (Rev. Q):1.3.6.1 Alternate Interrupt Vectors

Q:From the above, I have concluded the following, but is there any validity to the following ideas?
When the firmware created for F6733 is written to F6736, the UART interrupt vectors refer to the 0x3B80-0x3BFF area, but it is an undefined area, so the PC is jumping to an unintended area.

Please let me check a few things to avoid the above situation.

Q: Is it correct that the beginning of RAM indicated by "Alternate Interrupt Vectors" is 0x2B80-0x2BFF for F6733 and 0x3B80-0x3BFF for F6736?

Q:When using "Alternate Interrupt Vectors" in F6736, is it possible to change the vector location to 0x2BFF?
If this is not possible due to hardware, a brief explanation of the reason would be appreciated.

Best regards,
O.H

O.H said:

If the firmware content (linker command file) is changed for F6736, it works. So we expect no hardware problems.

I would expect that.

O.H said:

After checking the .cmd and .map files, we found that "Alternate Interrupt Vectors" were being used.
MSP430x5xx and MSP430x6xx Family User's Guide (Rev. Q):1.3.6.1 Alternate Interrupt Vectors

Can you describe how you made this discovery? Have they excluded 0x80 bytes from the top of RAM in the linker file to avoid the stack corrupting the interrupt vectors? Also, why are they using this feature?

O.H said:

Q: Is it correct that the beginning of RAM indicated by "Alternate Interrupt Vectors" is 0x2B80-0x2BFF for F6733 and 0x3B80-0x3BFF for F6736?

I think you mean the "top of RAM" rather than the beginning. The top (or end) of RAM is the highest address of the RAM sectors. Your address ranges are correct.

O.H said:

Q:When using "Alternate Interrupt Vectors" in F6736, is it possible to change the vector location to 0x2BFF?
If this is not possible due to hardware, a brief explanation of the reason would be appreciated.

I'm assuming this is handled by the hardware on each device (e.g. each device knows where its top of RAM is located), but I'll need to dig a little deeper to learn more. It may take a week before I can get back to you about this. In the meantime, here are some related threads that may help.

Interrupt Vector Relocation MSP430F5659

Use Ram as an alternate location for interrupt vector locations

How to use SYSRIVECT bit in register SYSCTL?

CCS/MSP430F5340: SYSRIVECT

Just to recap, the alternate interrupt vectors work on F6733 and F6736 when the device-specific linker file is used. Is that correct?

James Evans said:

Can you describe how you made this discovery? Have they excluded 0x80 bytes from the top of RAM in the linker file to avoid the stack corrupting the interrupt vectors? Also, why are they using this feature?

The __STACK_END is set to 0x2B80 for F6733 and 0x3B80 for F6736. They implement a custom bootloader. The customer use vectors relocated to RAM for normal application code execution (SYSRIVECT bit in the SYSCTL register is set to [1]).

James Evans said:

Just to recap, the alternate interrupt vectors work on F6733 and F6736 when the device-specific linker file is used. Is that correct?

Yes, that's right.

James Evans said:

I think you mean the "top of RAM" rather than the beginning. The top (or end) of RAM is the highest address of the RAM sectors. Your address ranges are correct.

James Evans said:

I'm assuming this is handled by the hardware on each device (e.g. each device knows where its top of RAM is located), but I'll need to dig a little deeper to learn more. It may take a week before I can get back to you about this. In the meantime, here are some related threads that may help.

Thank you for the reference information. I understand from other threads that it indicates the top (or END) of the RAM. I was hoping that I could reference the end of the sector being used in the linker command file settings, but that seems difficult.

Thank you for your time, and I look forward to the results of your investigation.

Best regards,
O.H

Hi,

We have conducted additional research on the customer side and will share the results.

Using the project created for the F6733, the customer changed the interrupt vector table to be placed (copied) in RAM to 0x3B80-0x3BFF. They have written this firmware to the F6736 and confirmed that it works with a simple evaluation.

The linker command file is set for the F6733. The customer used "Alternate Interrupt Vectors". When extracting the interrupt vector table into RAM, it determines the product model number from the Divice ID and dynamically changes the area to be extracted. No errors or warnings were generated by the compiler. By doing this, I believe they can write the same firmware to different products.

Could you give me some possible concerns about the above measures?
As the firmware uses an area (0x3B80 - 0x3BFF) that was not originally defined in the F6733, we are concerned that it may derive to some problems. By checking the possible concerns, we hope to be able to determine how much verification time will be required, so we would appreciate any insight you can lend us. Or, if you find a better solution, please let us know.

Best regards,
O.H

Hello,

Thanks again for the detailed update. It sounds like they are on the right path.

O.H said:

Using the project created for the F6733, the customer changed the interrupt vector table to be placed (copied) in RAM to 0x3B80-0x3BFF. They have written this firmware to the F6736 and confirmed that it works with a simple evaluation.

Let me summarize to make sure I understand.

O.H said:

The linker command file is set for the F6733. The customer used "Alternate Interrupt Vectors". When extracting the interrupt vector table into RAM, it determines the product model number from the Divice ID and dynamically changes the area to be extracted. No errors or warnings were generated by the compiler. By doing this, I believe they can write the same firmware to different products.

That makes sense. When not using alternate interrupt vectors, the same linker file can be used on a device with more memory assuming the two devices share the same lower memory sectors.

O.H said:

Could you give me some possible concerns about the above measures?
As the firmware uses an area (0x3B80 - 0x3BFF) that was not originally defined in the F6733, we are concerned that it may derive to some problems. By checking the possible concerns, we hope to be able to determine how much verification time will be required, so we would appreciate any insight you can lend us. Or, if you find a better solution, please let us know.

My only concern is that using the F6733 linker file prevents the full memory size from being used by the code on the F6736 device. In your F6733 project, if you're checking the device ID and never using the RAM addresses 0x3B80 to 0x3BFF on the F6733, I don't see an issue with that. If you use that same project on F6736, the RAM address range 0x3B80 to 0x3BFF is supported by the F6736 device, even though the range isn't explicitly declared as a section by the linker file.

Hello,

Sorry for the late reply.

We have not actually checked the following patterns, but I assume they are probably as perceived. The other patterns are as you recognize.

James Evans said:

My only concern is that using the F6733 linker file prevents the full memory size from being used by the code on the F6736 device. In your F6733 project, if you're checking the device ID and never using the RAM addresses 0x3B80 to 0x3BFF on the F6733, I don't see an issue with that. If you use that same project on F6736, the RAM address range 0x3B80 to 0x3BFF is supported by the F6736 device, even though the range isn't explicitly declared as a section by the linker file.

Thank you for your answer. I would like to verify this based on the information you provided.

Best regards,
O.H

Thanks for the update. As discussed earlier, their approach should work , but I did want to point out the vector redirection implementation method described in the MSPBoot – Main Memory Bootloader for MSP430 Microcontrollers app note as an alternative although there is some added latency between the interrupt request and when the code starts executing the ISR code.