This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi all! I'm getting started with a project on the MSP430FR5739, and I'm getting an unfamiliar compiler warning. Right now, I'm using the "MSP430FR57xx_uscia0_spi_10.asm" found in the TI Resource Explorer, and I'm having the warnings pop up in the following lines.
;------------------------------------------------------------------------------- ; Main loop here ;------------------------------------------------------------------------------- Mainloop bis.w #LPM0+GIE,SR ; Enter LPM0 w/ interrupt nop ; remain in LPM0
And below are the warnings that pop up:
[W0005] NOP required before set of GIE bit. #10247-D creating output section ".int56" without a SECTIONS specification #10202-D no suitable entry-point found; setting to 0
I try to ignore the warnings and run the code. It is able to locate the MSP-EXP430FR5739, and erase the memory. This error then pops up:
Load Program Error. File: C:\Users\<user>\workspace_v6_0_1\SPI_Assem\Debug\SPI_Assem.out: a data verification error occured, file load failed.
It also shows this error in the console.
MSP430: File Loader: Data verification failed at address 0x00000000 Please verify target memory and memory map. MSP430: GEL: File: C:\Users\<user>\workspace_v6_0_1\SPI_Assem\Debug\SPI_Assem.out: a data verification error occurred, file load failed.
I've looked around in the forums and user guide with no luck. I would like to know what this compiler warning actually means and, if possible, fix this issue. Thank you.
Hi dauletle,
For your first warning, about the NOP with GIE, please refer to the user's guide www.ti.com/lit/pdf/slau272 section 1.3.4.1 in the big Note at the bottom of the page. Basically, I think this warning is trying to help you avoid the situation listed in this note - by putting NOP before/after GIE access you can make sure that EINT and DINT or other GIE setting/clearing events aren't going to happen back-to-back. So it is general good advice to follow, and I think there are a couple of other related threads on this forum.
For your entry point issue, try the steps on this wiki page: http://processors.wiki.ti.com/index.php/Compiler/diagnostic_messages/10202
Regards,
Katie
Thank you for the quick reply! I'll go over everything in the order it was addressed.
Katie Pier said:For your first warning, about the NOP with GIE, please refer to the user's guide www.ti.com/lit/pdf/slau272 section 1.3.4.1 in the big Note at the bottom of the page.
That makes sense. I've added a "NOP" command before and after enabling the interrupt, and it looked like it removed the warning. The updated code is shown below:
;------------------------------------------------------------------------------- ; Main loop here ;------------------------------------------------------------------------------- Mainloop nop bis.w #LPM0+GIE,SR ; Enter LPM0 w/ interrupt nop
Katie Pier said:For your entry point issue, try the steps on this wiki page: http://processors.wiki.ti.com/index.php/Compiler/diagnostic_messages/10202
I followed the steps in the Remedy section of the link you've sent me, and that warning has been removed as well.
Below are the warnings that remain when I build the program.
#10247-D creating output section ".int56" without a SECTIONS specification
Also, the same error message in the pop-up window and the console still come up when I try to run the program on the experimenter board. What else can I try?
Hi dauletle,
I tried to reproduce your issue on an MSP-EXP430FR5739 board using CCSv6.0.1.00040, but I was unable to reproduce your problem.
Here were the steps I used:
1. Project > New CCS Project...
2. Select "Empty Assembly-only Project" and put in the settings for FR5739 and a project name
3. replace main.asm with the code from MSP430FR57xx_uscia0_spi_10.asm from the latest download of www.ti.com/lit/zip/slac491
Now if I build, I only get the warning about nop, not any of the other warnings you had. I added the nop, and then I built and loaded code with no warnings.
So I never saw the warning about .int56 - does anything sound different about our setup (CCS version, etc?)
Regards,
Katie
dauletle said:Below are the warnings that remain when I build the program.
#10247-D creating output section ".int56" without a SECTIONS specificationAlso, the same error message in the pop-up window and the console still come up when I try to run the program on the experimenter board. What else can I try?
The name of the section for the reset vector table entry for the MSP430FR5739 under CCS is ".reset", not ".int56". For msp430-elf gcc it's "__reset_vector" not "__interrupt_vector_56". Make your code and the linker script lnk_msp430fr5739.cmd consistent and it should be fine.
In the example that dauletle is using, .int56 is the USCI ISR (it's a SPI example).
It does sound like maybe there is something not matching with the linker file, so I'm wondering if maybe they are using an older version of CCS with an older linker file version, since I was unable to reproduce this warning in my version of CCS.
Katie Pier said:In the example that dauletle is using, .int56 is the USCI ISR (it's a SPI example).
That'd be the problem then. The 56'th interrupt vector on the FR5739 is the reset vector. The USCI vectors in the CCSv6 linker script are:
USCI_A1 : { * ( .int43 ) } > INT43 type = VECT_INIT
USCI_B0 : { * ( .int47 ) } > INT47 type = VECT_INIT
USCI_A0 : { * ( .int48 ) } > INT48 type = VECT_INIT
The example is wrong. (Note that the FR57xx chips were the first nominally 5xx chips that did not have a 64-element vector table, because the soft fuse bits are in the lower part of the memory that was originally documented as being the vector table.)
FWIW: The not-int56 linker addresses are what I have in CCS 5.5.0 and 6.0.0-190. I have no idea why it works for you; it shouldn't unless you have a really old CCS from back before everybody realized we were potentially overwriting the fuse by clearing all the vector entries.
dauletle said:I would like to know what this compiler warning actually means and, if possible, fix this issue.
I, on the other hand, would like to know which version of which compiler you are talking about.
You're right, I didn't understand what you meant before. Now I dug a bit deeper and I see that in the datasheet USCI_A0 entry in the table is at address 0xFFF0, which is defined in the linker as .int48. It is also strange that this was not throwing any warnings when I built in my version since there is no definition in the linker file for .int56 - in truth it was not putting this entry anywhere, since it looks like .reset is where .int55 would be, so .int56 would be in some non-existent part of memory 0x10000.
Thanks for pointing this out and explaining - I'll file a bug on this code example and also go check the others to see what they are using for the interrupts as well.
@dauletle
Go check your linker file, find the entry for USCI_A0 or for address 0xFFF0 (as you can see this is the address for USCI_A0 entry in Table 6-1 in the datasheet www.ti.com/lit/gpn/msp430fr5739 ) - you should see this should be .int48. Change the .asm file to use .int48 as the section for USCI_ISR in your code.
Regards,
Katie
Thank you everyone for all the help and explanation. It looks like the issue was caused a mismatch in the linker file and the example code. As for reference, I'm using CCS Version: 6.0.1.00040 on a Windows 7 x64 OS.
Katie Pier said:Change the .asm file to use .int48 as the section for USCI_ISR in your code.
Below are my changes:
;------------------------------------------------------------------------------ ; Interrupt Vectors ;------------------------------------------------------------------------------ .sect ".reset" ; MSP430 RESET Vector .short RESET ; .sect ".int48" ; USCI_A0_VECTOR .short USCI_ISR ; .end
And for even further reference, I found the list of linker addresses and its associated interrupts it represents:
/* MSP430 Interrupt vectors */ .int00 : {} > INT00 .int01 : {} > INT01 .int02 : {} > INT02 .int03 : {} > INT03 .int04 : {} > INT04 .int05 : {} > INT05 .int06 : {} > INT06 .int07 : {} > INT07 .int08 : {} > INT08 .int09 : {} > INT09 .int10 : {} > INT10 .int11 : {} > INT11 .int12 : {} > INT12 .int13 : {} > INT13 .int14 : {} > INT14 .int15 : {} > INT15 .int16 : {} > INT16 .int17 : {} > INT17 .int18 : {} > INT18 .int19 : {} > INT19 .int20 : {} > INT20 .int21 : {} > INT21 .int22 : {} > INT22 .int23 : {} > INT23 .int24 : {} > INT24 .int25 : {} > INT25 .int26 : {} > INT26 .int27 : {} > INT27 .int28 : {} > INT28 .int29 : {} > INT29 .int30 : {} > INT30 RTC : { * ( .int31 ) } > INT31 type = VECT_INIT PORT4 : { * ( .int32 ) } > INT32 type = VECT_INIT PORT3 : { * ( .int33 ) } > INT33 type = VECT_INIT TIMER2_B1 : { * ( .int34 ) } > INT34 type = VECT_INIT TIMER2_B0 : { * ( .int35 ) } > INT35 type = VECT_INIT PORT2 : { * ( .int36 ) } > INT36 type = VECT_INIT TIMER1_B1 : { * ( .int37 ) } > INT37 type = VECT_INIT TIMER1_B0 : { * ( .int38 ) } > INT38 type = VECT_INIT PORT1 : { * ( .int39 ) } > INT39 type = VECT_INIT TIMER1_A1 : { * ( .int40 ) } > INT40 type = VECT_INIT TIMER1_A0 : { * ( .int41 ) } > INT41 type = VECT_INIT DMA : { * ( .int42 ) } > INT42 type = VECT_INIT USCI_A1 : { * ( .int43 ) } > INT43 type = VECT_INIT TIMER0_A1 : { * ( .int44 ) } > INT44 type = VECT_INIT TIMER0_A0 : { * ( .int45 ) } > INT45 type = VECT_INIT ADC10 : { * ( .int46 ) } > INT46 type = VECT_INIT USCI_B0 : { * ( .int47 ) } > INT47 type = VECT_INIT USCI_A0 : { * ( .int48 ) } > INT48 type = VECT_INIT WDT : { * ( .int49 ) } > INT49 type = VECT_INIT TIMER0_B1 : { * ( .int50 ) } > INT50 type = VECT_INIT TIMER0_B0 : { * ( .int51 ) } > INT51 type = VECT_INIT COMP_D : { * ( .int52 ) } > INT52 type = VECT_INIT UNMI : { * ( .int53 ) } > INT53 type = VECT_INIT SYSNMI : { * ( .int54 ) } > INT54 type = VECT_INIT .reset : {} > RESET /* MSP430 Reset vector */
The code loads onto the experimenter board with no warnings or errors. Thank you all for all the help and explanations.
Katie Pier said:For your first warning, about the NOP with GIE, please refer to the user's guide www.ti.com/lit/pdf/slau272 section 1.3.4.1 in the big Note at the bottom of the page. Basically, I think this warning is trying to help you avoid the situation listed in this note - by putting NOP before/after GIE access you can make sure that EINT and DINT or other GIE setting/clearing events aren't going to happen back-to-back. So it is general good advice to follow, and I think there are a couple of other related threads on this forum.
I think that is an overkill, especially in Assembly code.
old_cow_yellow said:I think that is an overkill, especially in Assembly code.
Agreed. EINT must not be followed by DINT and DINT must not be immediately followed by EINT or any critical code sequence. Because after DINT, an interrupt may still happen after the next instruction.
But generally demanding a NOP before EINT is overkill. It’s not even required after DINT, as any other non-critical operation will do.
**Attention** This is a public forum