Part Number: MSP430F2619
Hello,
I am having a strange lock-up in some firmware written in C on a MSP430F2619 (actually the high temperature SPM part, but I don't want this post ending up in the HiRel forums :)
It is in the middle of some UART communications on USCI A0 where the CPU receives its own transmissions. I'm using TX and RX interrupts. The transmit code puts as much as possible into a shared buffer and then enters LPM to allow space to appear in the buffer. I have a function lpm() that checks some things and then goes into the appropriate LPM (either 1 or 3) and then returns after returning to active mode. The generated code is like:
# Other code
BIS.W #2,&IE2 # Enable TX interrupts to allow space to appear in buffer
CALLA #lpm
BIC.W #2,&IE2 # Disable TX interrupts while copying into shared buffer
# Later...
lpm:
# Check some things
BIS.W #D8,SR
RETA
I managed to break into the processor after it locked using IAR and the MSP-FET430UIF but it does not stop the CPU where it is, it always ends up resetting the CPU saying "Cannot determine device state". However, the SP is pointing at the following contents.
Return address points to caller of lpm()
Return address points to RETA within lpm()
SP -> SR from ISR entry
And I can see register contents that would have been preserved during the ISR further down the stack.
I tried adding a NOP between the LPM and the RETA as per the CPU19 errata and the lock up no longer manifests itself. However, the CPU19 errata was only in a family errata sheet (SLAZ033) and was removed from the device specific datasheet (SLAZ189) so I'm not sure that it is possible to rely on that as a fix.
I also tried adding some diagnostic code to one of the ISRs and that moved the lock-up (I was able to transmit some more before it locked). I have tried reducing the code and I cannot generate the lock-up with the reduced code (so, sorry I do not have code that I can share).
Breaking the link from RX to TX also allows the code to function OK, but is not the normal situation for the device. From that I'm happy that the code is OK and I'm quite sure there are no interactions between RX and TX ISRs and code.
I am not sure whether I can treat the CPU19 workaround as a valid fix in this case. It seems to be but is it still applicable to the 2619 when it is not in the errata sheet?
