Having problems with C# emitResetPulse()

LeafLabs Garden » Development

Having problems with C# emitResetPulse()

(6 posts) (4 voices)

Started 2 years ago by visualmicro2
Latest reply from ala42

visualmicro2
Member

Can anyone help please. I am trying to replicate resetting to the bootloader using serial on a Rev3 board. Dfu works fine if I manually reset, maple uploads fine but I can't get a C# program to replicate the serial reset.

I have an open serial port at 115200 baud, but when I attempt to reset the serial port "locks up" after writing 1EAF and does not work until the board has been reset.

Interestingly the port still shows as being available after the reset fails but is unusable. I have tried various combinations, the default delay in the maple code is 50ms but have tried various shorted or longer delays.

` serialPort.BaudRate = 115200;

// try to toggle DTR/RTS (old scheme)
serialPort.RtsEnable = false;
serialPort.DtrEnable = false;
serialPort.DtrEnable = true;

Thread.Sleep(idelay);

serialPort.DtrEnable = false;

// try magic number
serialPort.RtsEnable = true;
serialPort.DtrEnable = true;
Thread.Sleep(idelay);

serialPort.DtrEnable = false;

Thread.Sleep(idelay);

serialPort.Write("1EAF");

//Thread.Sleep(idelay);

Thanks

Tim
`

Posted 2 years ago #
mlundinse
Member

After the reset sequence the Maple USB is no longer a serial device but a dfu device. So your C# serial connection will get cut off, and this happens without your program closing the serial port. Then a few seconds later, if you have a working sketch on your board, the dfu bootloader will start the sketch and the USB Serial port will reappear.

Regards
Magnus

Posted 2 years ago #
gbulmer
Moderator

visualmicro2 - What OS are you using, Windows?

When you reset the board, the USB port stops being a USB serial device, and is a USB DFU device.
So I would expect the serial port to "lock up" because there is no longer a device there, and AFAIK, an OS, e.g. Windows, will take a little bit of time to notice.

Further, on Windows, the serial port will be a different COM port when the Maple returns from being a DFU device. So I wouldn't expect to be able to talk to it as the same device (on Windows).

After the board is reset, you could open it as a DFU device, and upload.

So, I believe you will need to close the serialPort after you've done the reset and serialPort.Write("1EAF");. Then find the port again (a different COM on Windows) if you want to talk to the board.

Posted 2 years ago #
visualmicro2
Member

Thanks for the replies. Yes I agree the port will be closed after the reset code has completed.

The c# code is having no problems finding the device with dfu-util when in manual/perpetual bootloader mode, or with normal serial>SerialUSB. (Yes thanks, I realize it can take a few seconds for the device to transition in and then out of dfu mode.

After investigating some more it appears the maple is left in some strange state after writing the DTR / "1EAF" to the board. After writing 1EAF, the usb com port disappears as expected but the board is not found by dfu-util and the reset button fails to cause the board to reboot and subsequently appear as a serial usb device (after a few secs).

After writing 1EAF, the only way to restore the board to a working state is to disconnect the usb for a few seconds then reconnect. It seems like the 1EAF is doing something but not everything :)

Uggh, thanks for any help.

Posted 2 years ago #
visualmicro2
Member

Ignore the comment about the reset button failing. It was my test app that thought the port wan't coming back up after pressing reset.

So it's really just that I am too stupid to work out how to properly send the proper DTR / "1EAF" to the port as ASCII :)

Am I right in thinking the 1EAF needs to be sent at 115200 baud?

Posted 2 years ago #
ala42
Member

The baud rate on the virtual com port does not matter.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.