MSP430FR5969 rev E: SYSRSTIV = 30

Hoyt,

The reset portion could be several factors and you could try the following. Give the following items a check to see if it could resolve your issue.

1. Check if your power is stable on your new PCB.

2. Are you using the MPU on the device? If so, check if your access rights are properly set.

3. Have you checked the current consumption of your new PCB if there is any access current that is not accounted for?

4. Could you double check if the generated code is actually writing to RAM memory? and not a peripheral memory map? It is highly possible that it is writing to a peripheral memory map that you are not supposed to thus causing the device to reset.

Regards,

William

The reset occurs after only a dozen or so instructions, stop watchdog, collect Sys registers for analysis, then into a clear ram loop where it resets. 

Further testing showed that the REV D processor works fine in the MSP-430RSZ48C test board, but the

REV E fails in the same test board.  The write 0 to RAM address 23FE ( mov #0, 1C00h(R11) ) fails.

This fails even if R11 is set to 0 so it's not the boundary of RAM that's the problem.

The RAM is not cleared before the reset happens.

Please suggest a work-around.

Thanks.

Here's the actual troblesome code, but note that if I skip this code, the next RAM write also resets.

RamClr:
00444E 403B 0800 mov.w #0x800,R11
sub #2,r11
RamClrLoop:
004452 832B decd.w R11
mov #0,RAMbegin(r11)
004454 438B 1C00 clr.w 0x1C00(R11)
jnz RamClrLoop
004458 23FC jne RamClrLoop
call #SetupGPIOs // special case: P2.7 RTS low to allow Bluetooth to send to us.
00445A 12B0 4658 call #SetupGPIOs
call #ButtonTest // Check buttons pressed while power applied for special function
00445E 12B0 462E call #ButtonTest
call #SetupMPU // Protect ourself
004462 12B0 45BA call #SetupMPU
call #CRCsub

Hoyt,

How fast are you running your CPU speed at? If you are running your CPU above 8MHz and moving to Rev E silicon, you may want to consult the migration document as mentioned below. One thing that we changed in Rev E is that you now have to enable the FRAM wait-states if you are operating the CPU above 8MHz.

If you comment out your MPU code, do you still observe this behavior?

Have you got a chance to take a look at this migration document? Migrating from XMS430FR5969 Revision D to Revision E 

Regards,

William

Solved, thanks, I had read the migration and errata, but accidentally set the 1 wait state in bit 0 instead of bit 4 of FRCTL0, secondly, IAR needed to be closed and reopened to accept the new code, as it's programmed via JTAG and an ELPROTRONIC device ( Rev E won't program via IAR using Spy-BiWire ), So now the code runs  ok on the demo board.

Other issues:  I need to use the MSP430FR5739 demo board's USB debug interface with IAR,

and even with that, it won't download code, only "attach without downloading".

 IAR won't work with either the TI MSP-FET-430UIF or the Elprotronic FlashPro430 at all.

Hoyt,

What version of IAR are you using?

Regards,

William

I would recommend upgrading your IAR to the latest version (5.60.5). They made several updates to the download drivers especially for MSP430FR5969 Rev E silicon.

Upgrade accomplished.

FWIW, the Elprotronic FlashPro430 device is still not usable with  IAR.

the TI MSP-FET430UIF only works with 4 wire JTAG , not Spy-BiWire ( both tested on the TI Z4BC demo platform).

The MSP430-EXP430FR5739 USB debug section is the only board I can use for Spy-BiWire on the MSP4305969.

William Goh said:

It is highly possible that it is writing to a peripheral memory map that you are not supposed to

Thanks Hoyt for the feedback. We'll take a look at it and work with our 3rd parties in resolving it.

JMG,

I was able to dig up some information here. It is another flag that would get set when the wait states are violated in manual mode. The flag is also used for other reasons that I am trying to find out more info about. But, the recommended way to check if you violated the wait states is by reading SYSSNIV register ACCTEIFG flag.

Regards,

William

William Goh said:

I was able to dig up some information here

William Goh said:

the recommended way to check if you violated the wait states is by reading SYSSNIV register ACCTEIFG flag.

I'm in a similar predicament.  I have a custom board with the Rev E MSP430FR5969 and the MSP-FET430UIF driven by the latest Elprotronic software.  I've tried two different programmers and two different boards with the micro.  The host software cannot make contact with the micro using Spy-Bi-Wire.  My programmers are version 1.4a.  The Elprotronic host app is version 3.1-2.  Programmer firmware is version 3.03.01.003.

If there an issue with this new micro?

I see the opposite:  Spy-Bi-Wire works wonderfully, but BSL doesn't work.  BSL works on Rev. D but not E.

Gregory at Elprotronic verified BSL doesn't work on Rev. E.

BTW,  I'm having problems with the A/D converter. It was working perfectly on one board, but subsequently new

boards it didn't work at all ( but on one it mysteriously just started working after a while ( not temperature dependent)).

When I store 0x6690 into address 0x800, it reads back as 3, it just won't take.  Do you have any thoughts on that?

On yet another matter I had a bis.b instruction fail to set the bit on some occasions, but when I changed it to

bis it became reliable.

Thanks

Regarding the ADC12, I had a hunch so I  wrote 0 to 0x800 before setting it up, it started ok.  I'll do further testing.

It should have defaulted to 0.

Ok, disregard the problem. I found it :-) .   An interrupt tried to start a conversion before the initialization was complete.

Sorry for the trouble report.

Don,

It is highly possible that Elprotronic's tool may not be updated yet for Rev E silicon as this is a new experimental silicon revision. What you can do is to copy MSP430.DLL from c:/ti/ccsv5/ccs_base/DebugServer/drivers and replace it inside Elprotronic tool.

This assumes you have the latest version of CCS to communicate with the device first.

Regards,

William

I'm using the Tag-Connect for connection between the MSP430RF5969 and MSP-FET430UIF.  So it turns out I needed to add the 330 Ohm resistor to the adapter to make Spy-Bi-Wire work.  With the resistor in place the Wolverine and debugger are working great.  Thanks for the replies and thanks to Neil at Tag-Connect for the help!

D-

I'm using the Tag-Connect for connection between the MSP430RF5969 and MSP-FET430UIF.  So it turns out I needed to add the 330 Ohm resistor to the adapter to make Spy-Bi-Wire work.  With the resistor in place the Wolverine and debugger are working great.  Thanks for the replies and thanks to Neil at Tag-Connect for the help!

D-