Usage of NMI

Arun Balachandran2 said:

1. Will it affect while flashing the code using spy by wire.

No, indeed as soon as TEST goes high to enable SBW function, both functions of RST#/NMI are disabled, so flashing will not be a problem. Of course the same can not be said for debugging.

Arun Balachandran2 said:

2. Will(NMI interrupt) this act just like other interrupts, that is after servicing using interrupt routine will it continue with the address stored program counter(RETI instruction).

Definitely yes, that's right.

Regards,

Peppe

Arun Balachandran2 said:

2. Will(NMI interrupt) this act just like other interrupts, that is after servicing using interrupt routine will it continue with the address stored program counter(RETI instruction).

Switching the RST pin to NMI effectively disables the bootstrap loader as well as (in most cases) debugging and perhaps even firmware upload through JTAG. Since the RST pin doesn't trigger a reset anymore, the BSL cannot be invoked and the debugger cannot reset the MSP to get a clean entry point.

My recommendation is to fix the spikes in the hardware. Things like that shouldn't happen. If they do, the hardware is faulty and you shouldn't try to fix it in software. This is fragile at best.

Jens-Michael Gross said:

If they do, the hardware is faulty and you shouldn't try to fix it in software.

Indeed. We happen to say - you shall fix cause instead of effect. Because there's possibility that you don't know all the effects of single cause.

Jens-Michael Gross said:

...  NMI is always enabled, even during your startup code...

NMI are not maskable by GIE=0. But are enabled/disabled individually by the firmware. They are disabled at power up. They are not enabled by the c startup code (unless you do it deliberately).

Jens-Michael Gross said:

... Switching the RST pin to NMI effectively disables the bootstrap loader as well as (in most cases) debugging and perhaps even firmware upload through JTAG. Since the RST pin doesn't trigger a reset anymore, the BSL cannot be invoked and the debugger cannot reset the MSP to get a clean entry point. ..

Kind of true, but it is the fault of the tools you used to invoke BSL, SBW, or JTAG. They should have hold the RST/NMI pin low before they power up the target chip. This way your firmware in the Flash of the target has no chance to do anything.

old_cow_yellow said:

But are enabled/disabled individually by the firmware.

I also use the NMI interrupt on Flash access violation (ACCVIE) and NMI input RESET pin (NMIIE).

Despite the fact my application is working well, sometime I could'nt use the SBW as long as my application is powered (batterie bowerd portable application).
I have to leave out the batteries to reinitialise correctly the SBW. Anyone have an idea witch bits/register is responsable of this trouble?

My application has a bit-bang USB that can access any memory locations, so  I would like to know with bit/register I will have to modify.

I try to clear both ACCVIE & NMIEE bits without any success....

Thanks for your help.

Pierre-Yves

Pierre-Yves MULLER said:

I also use the NMI interrupt on Flash access violation (ACCVIE) and NMI input RESET pin (NMIIE).

Despite the fact my application is working well, sometime I could'nt use the SBW as long as my application is powered (batterie bowerd portable application).
I have to leave out the batteries to reinitialise correctly the SBW. Anyone have an idea witch bits/register is responsable of this trouble?

My application has a bit-bang USB that can access any memory locations, so  I would like to know with bit/register I will have to modify.

I try to clear both ACCVIE & NMIEE bits without any success....

Thanks for your help.

Pierre-Yves

I said earlier that: "... but it is the fault of the tools you used to invoke BSL, SBW, or JTAG. They should have hold the RST/NMI pin low before they power up the target chip. This way your firmware in the Flash of the target has no chance to do anything. ...". In your case, they should have told you to remove the battery.

By the way, I made a device with a MSP in a sealed box and cold not run BSL without first open the box to make connections to the BSL pins.

Thank you so much "old_cow_yellow" to take time to answer me !

For your information I use a SBW launchpad. !...

As I wrote before, because I have an another access to the memory via a bit-bang USB, I can solve this trouble by erasing the last sector of FLASH CODE memory (FEF0h to FFFFH). So the SBW works again!

Any idea why this action "reset" the SBW communication ?

Thank's,

Pierre-Yves

Location 0xFFFE-0xFFFF (part of last sector of Flash) contains the "reset vector" that points to the beginning of your code. When you erase this, your code will not be executed any more, and will not change the function of RST pin any more.

Yes I know you are rignt, but when my application is running if I clear the NMIIE bit it should release the RESET fonction. ? (no more NMI interrupt) 

S0 why the SBW communication still do not work ?

Finally I got the answer to release the SBW communication:

With the bit-bang USB implemented on my application , change the following bits:

1) Clear NMIIE in IE1 (byte register  at memory address :30h)

Right.

It is WDTNMI that changes the usage of the pin. NMIIE does not matter.

old_cow_yellow said:

NMIIE does not matter.