SerialUSB goes dead after a software reset

I have the Arduino Due with the Sam3x8e microcontroller.

I want to do a reset from inside the software on the micrcontroller, and I'm using the following code on the sam3x8e:

__DSB;
SCB->AIRCR = ((0x5FA << SCB_AIRCR_VECTKEY_Pos) | SCB_AIRCR_SYSRESETREQ_Msk);

This seems to work to reset the microcontroller, however there's a problem. The Arduino Due board is connected to a PC via the USB-to-serial interface. The PC is running MS-Windows version 10. When the microcontroller resets, I can hear MS-Windows make the "di dum" sound that it makes when a USB device is disconnected -- and this is how I can no longer communicate with the microcontroller.

I want to continue to communicate with the microcontroller via the USB-to-serial interface after I reset the microcontroller. How can I do this?

I can think of two possibilities here:
Possibility 1: Stop the Arduino Due from reporting that it's turned off, and so MS-Windows won't make the "di dum" sound.
Possiblity 2: After the "di dum" sound, execute code on the microcontroller that makes MS-Windows make the "dum dem" sound to indicate something has just connected.

Any ideas?

The obvious question is why ?

It would be a lot handier just to power cycle the microcontroller, but the person who is testing it is a few thousand miles away and he is TeamViewer'ed into the Microsoft Windows PC that's connected to the microcontroller.

So instead of turning it off and back on, he's iissuing a command over RS232 to tell it to reset.

The solution will probably have to be on the PC side as when you reset the Arduino the pins tristate and the USB is no longer active. As it is programed to do the windows drops the connection and continues to search for a connection. I will take a SWAG and say you may be able to find an active USB adapter and/or isolator that may work.

I could just change the program so that it looks something like:

> void setup(void)
> {
>     /* Entire contents of this function
>         has been moved to "my_setup"
>     */
> }
>
>
> bool reboot = true;
>
> void loop(void)
> {
>     if ( reboot )
>     {
>         my_setup();
>         reboot = false;
>     }
>
>     /* The rest of the Superloop goes here */
> }
>
>
> void my_setup(void)
> {
>     /* All the start-up code goes in here */
> }

Then I would just have to re-construct all the global objects using "placement new", and also reset the heap. I think it might be doable.

Will the code in my previous post work, or will I be missing some special code that gets called every time the function "loop" is called?

Sorry I do not know that processor so I could not give you an accurate answer.

Maybe change the software reset methodology:

Obviously, you want the C++ setup code to properly handle the USB reset so Windows will react just as if the cable was unplugged and plug in; that is Plug'nPlay needs to enumerate fully. If still problematic, you may need to use an output line to force the atmega16U2 reset pin low for a few hundredth milliseconds and then software reboot the Due.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.