• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Answers 3 answers
  • Subscribers 80 subscribers
  • Views 29445 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/MSP430F5528: Strange RESETs after MSP-FET-Firmware Upgrade

Mathias Bachmayer
Intellectual 320 points
Part Number: MSP430F5528
Other Parts Discussed in Thread: MSP-FET,

Tool/software: Code Composer Studio

Hello,

hard to explain - hopefully it is hardware issue - in the end total Resets (Like PURs! Programm starts from zero! But is somehow lost from debugger, it can be stopped, but PC is total out of controll, but the software still runs. If Breakpoints are set at functions, the code must come through, nothing happens. Strange, because normally if a PUR occurs, Debug connections are lost - at least in my impression).

BUT the hardware under test (10 pieces!) performed well for weeks and several software releases.

The only thing what happened two days ago, was an unintended "MSP-FET-UPDATE". Normally I declined it - but it nerved....

Well, since that event, devices show a very very strange behaviour: They reset, at least at a reproducable stage of the code...! But this piece of code is actually the oldest and most tested one of the project. 

Questions:

#A: Has anybody else observed similar phenomena after updating the MSP-FET device?

#B:  How to control the update behaviour? CAN I suppress it ?

#C: Can I degrade the MSP-FET and Compiler/CCS Studio to older versions?

#D:  How can I load a hex-file without building the project? I've got older versions, till now untouched, I would like to flash the old hex-Files.

Thank You in advance - I hope this is the issue... but I keep on investigating the hardware!

  • 0
    TI__Guru 56685 points
    Hello Mathias,

    More than likely the upgrade to your MSPFET did not cause these resets for your device. We need to determine here what is the cause of your resets and then narrow down the problem from there. Luckily the MSP430F5528 contains a registers that tells you the cause of the last reset that you can check at the beginning of your application. You can find more information about this by searching our E2E forum and by checking out the link below.

    processors.wiki.ti.com/.../Handling_MSP430_System_Reset_Events
  • 0 in reply to Jace H
    Intellectual 320 points

    Hello Jace,

    now for 100 % : there are now voltage drops below 2.2 Volts.

    Till now the register SYSRSTIV reads as 0x000A after start up and also after the strange issue occurrs.  But 0x0000 after replay of the current debug session.

    With best regards

  • 0 in reply to Mathias Bachmayer
    Intellectual 320 points
    Additional Information:

    There are two devices, which show this strange behaviour! Not all 10!!!!

    Rest works normal, as it should!

    How probable is it/can we check it, if two uCs of a batch of 1000 pieces, have a memory (or something like that) mistake?

    It's spuky! I think the probability for this is a matter of malfunction of the uCs is nearly zero.

    Devices are all from the same batch - Boards (checked under microscope - as far as checkable) don't show any difference.

    Information: XT2 is not connected - for power saving reasons, also via XT2OFF disabled.

    What should I check in addition - or do You think the two boards have a defect uC on board?

    With best regards
  • 0 in reply to Mathias Bachmayer
    Intellectual 320 points

    Is there a possibility to run a uC Self test? To test if the memory works properly, the PC, the ISR System?

    I'll implement an UART-Based printout of the relevant uC registers, at startup. 

    If there is no possibility to check this things, I'll have to change the chip for testing.

  • 0 in reply to Mathias Bachmayer
    Mastermind 9045 points
    I don't think there is a self-test procedure inside MSP430.

    Have you tired this: In CCS, You can enable an option in debugger to set a breakpoint for reset event. So, if MCU is reset then the PC (program counter) will stop at the breakpoint.

    Btw, you might also want to use "hardware breakpoint" instead of "software breakpoint".

    And, before doing more testing, you should upgrade your CCS and all its software packages/drivers up-to-date at first.
  • 0 in reply to Robert Chen
    Intellectual 320 points

    Thank You Robert,

    I've updated CCS and installed it on another computer as reference - no difference obvious.

    I'll checkout this debugger option.

    The total crazy thing: This type of reset occurs, during UART-Operation - but not the very first Operation, actually there are a lot of operations ahead. Active Interrupts: UART_A0 and the Watchdog Timerinterrupt. 

  • 0 in reply to Robert Chen
    Intellectual 320 points

    Other (paranoia) question regarding the same trouble shooting: Is everything well defined? I'm not so long working with the MSP430 (cool device, and cool documentation for sure! Thank You TI!) - so I'm not really safe regarding the management of the clocks. As far as I see my registers and my scope by inspecting the timings, the system works. Also compared to the launch-pad circuits and easy programs. There is no XT2 Crystal - it's free - for power saving reasons.One thing not to clear to me: PORT C? On which Pins is it to find?

    Question because of a former remark #10372-D: (ULP 4.1) Detected uninitialized Port C in this project. Recommend initializing all unused ports to eliminate wasted current consumption on unused pins.

    I've just defined it at the very first line of code by:     PCDIR=0x00; PCREN=0xff; PCOUT=0x00;

    On which Pins is actually this PortC? What is its function?



    Important to know: I don't like beans and such stuff - I prefer coding by documentation on register level.


    With best regards
    Dr. Bachmayer

  • 0 in reply to Mathias Bachmayer
    TI__Guru 56685 points
    Hello Mathias,

    You state that you have no voltage drops at 2.2V. One thing to consider here is your SVS settings, VCORE Level, and clock settings. In order to achieve higher clock frequencies, the VCORE level must be raised (default clock is 1MHz). At VCORE Level 3, you can achieve the highest frequencies of the device. There is also a DVCC restriction at different VCORE levels. These can be found in the datasheet, but for VCORE Level 3, DVCC must not go below 2.4V (20+ MHz operations) and VCORE Level 2 must not go below 2.2V ( 12-20 MHz operation). Please see the data sheet for more information (Figure 5-1). Please check your clock settings and VCORE level to ensure this relationship is not violated.

    With the process of raising VCORE, you also change your SVS settings. The SVS will automatically reset your device is you go below a certain voltage. The highest voltage the SVS High Side will reset your device has a typical value of 2.18V for this device (max value of 2.31V). At 2.2V, you could be hitting the max level on some chips, causing a Reset. You cna also set the SVS high side monitor (SVSMHS) to reset your device at higher voltages. This has to be manually set however, and is very useful when using the device at VCORE Level 3.
  • 0 in reply to Jace H
    Intellectual 320 points

    Dear Jace,

    I'll check this also.

    But in my application I use all the benefits of the MSP430. I even controll the power supply voltage between 3V3 and 1V8.

    It works - also with 1V8, what is my sleep voltage.

    Clock is not touched - so I think it is 1Mhz (quite sure, due to UART configurations...).

    All my software does is setting up the watchdog as ISR - source (with lowest possible periodes), configure I2C, SPI, and UART.

    All worked and was step by step developed and controlled for function via scope/signal analyzer.

    I'll tell You asap the results regarding the Reset source.

    The mentioned functionalities are not used at the same time - so ISR interference can't be the issue.

    What drives me crazy - when the mentioned voltage drop occurs (at activating a heavy load member of my circuitry), the reset doesn't occur at all. This member (interfaced via UART) sends the initial routine - all fine. BUT, when my UART starts to send it's first commands, it happens. But when I step through - nothing happens, because of the missed answers..... so hard to debug...

    I've not only measured the drops, I've additionally added big capacitors, even a strong power supply - it didn't change the effect.

    And again: This is not seen on all devices.

    Therefore - if it is probably no failure on the IC itself, I think it has to be something like a undefined input. But which inputs could be responsible for such a total reset? The reset Pin has an Pull up of 47kOhm (Pin64 of MSP430F5228 RGC package). Other basic circuitry like on a launchpad: 1k between PUR and PU.0, 1M between PU.0 and VSSU (GND). SBWTCK is open (correct?).

    Thank You very much in advance - for sure a stupid beginner mistake, but a cruel one, because it came up very very very late AND not at all devices....

    With best regards
    Mathias

  • 0 in reply to Mathias Bachmayer
    TI__Guru 56685 points
    Hello Mathias,

    If you have the watchdog enabled, and you are still only at 1MHz, I can envision a situation where you tx/rx a lot of data that is blocking you from servicing the watchdog. Since you do not service the watchdog in time, it resets your part.
  • 0 in reply to Jace H
    Intellectual 320 points

    Dear Jace,

    the watchdog is regarding its reset functionality disabled  - I use it as a pure Timer Interrupt providing my Time Base for my statemachines:

    Setting One: WDTCTL = WDTPW | 0x0040 |0x0007 | WDTTMSEL; // 7 msek Period for ISR

    Setting TWO: WDTCTL = WDTPW | 0x0040 |0x0005 | WDTTMSEL; // 873 msek Period for ISR

    SFRIE1|=WDTIE;

    Correct? Or is the watchdog still anyhow awake?

    Moreover I set

    UCSCTL6|=XT2OFF;


    I'll go now through all the hints (especially from Robert regarding the Breakpoint for resets) and give You a detailed report.

    Thank's a lot

    With best regards

  • 0 in reply to Robert Chen
    Intellectual 320 points
    Dear Robert,

    could You please explain how to setup this debug feature in more detail? Is it the "Halt at program termination" under "Debug/Program/Memory Load Options" isn't what You ment - right?

    Thank You in advance
  • 0 in reply to Mathias Bachmayer
    Intellectual 320 points

    FYI regarding SYSRSTIV (redundant Information):

    long Register;
    void main(void){
    Register = SYSRSTIV;

    delivers:
    <watched expressions>|<RegisterView of SYSRSTIV>:
    Fresh Loaded : 0x00000000|0x0000
    After first Reset (manually halted) : 0x0000000A|0x0000

    What looks for me (if I understand the Wiki from Jace correctly) a security violation occurs?!!!!

    What means this? I guess it means a pointer is running amok? I'll check the UART-Write routines...

    processors.wiki.ti.com/.../SYSRSTIV_Register_options.png

  • 0 in reply to Mathias Bachmayer
    TI__Guru 56685 points
    Mathias,

    A "Security Violation" means you are trying to access a part of the device (read memory map) is not allowed. This could be reserved space, boot memory, or undefined parts of the memory map. The most likely cause of this could be stack overflow, pointer mismatches, or array indexes out of bounds.
  • 0 in reply to Jace H
    Intellectual 320 points
    Ok - so the BOR has for sure nothing to do with the BOR (Brown out Reset) I've found in the MSP datasheet - which gives a quite interesting defintion regarding DV/DT?

    Because, I don't get it, why it works with the other devices. Moreover it is a ring-buffer.
  • 0 in reply to Mathias Bachmayer
    TI__Guru 56685 points
    Mathias,

    The BOR Circuit will cause a BOR, but there are several sources that can cause a BOR.
  • 0 in reply to Jace H
    Intellectual 320 points

    Dear Jace,

    Ok, thank You. I'll investigate the UART-Connection - regarding pointer issues.


    But thank YOu very very much!

    With best regards

  • 0 in reply to Mathias Bachmayer
    Intellectual 320 points

    Bug found! The Slave device blasts out suddenly 11kByte of data trash - like a denial of service attack ... - during development only <200 Bytes observed. The initialisation routine, didn't take a possible roll over into account (Ringbuffer is 4000 Bytes big).  

  • 0 in reply to Mathias Bachmayer
    Intellectual 320 points

    Bug found, but now facing some program stops caused by a blue arrow with a hint "MSP-430 Debug Call Stack".

    I've reset debugger settings to default (because of searching for Robert's hint regarding the Debugger setting) - but no change.

    The device works, if I disconnect it totally from the debugger after flashing, initiating the communication.

    But if I let the debugger connected, the program stops randomly anywhere with this hint "MSP-430 Debug Call Stack". What does this mean?


  • 0 in reply to Jace H
    Intellectual 320 points

    Could please anybody explain me, what the "MSP-430 Debug Stack" Message means? Thank You!

  • 0 in reply to Mathias Bachmayer
    TI__Guru 56685 points
    Mathias,

    I have not seen this error before. If you can take a screenshot showing the message logs for the issue that could be helpful.
  • 0 in reply to Jace H
    Intellectual 320 points
    Dear Jace,

    thank You very much for Your thoughts - You are also right, but I've coped with this problem in an earlier stage of the project by downspeeding the UART of the bad device.

    This issue is actually solved - the reason for this strange resets was an undocumented behaviour of a connectivity module, which blasts 11kByte code out.

    How can I close this issue - or delete it, because I'm sorry for the wrong subject, it was a matter of accident the problem occured just after upgrading the MSPFET.

    Thank You
    Mathias

**Attention** This is a public forum