NEW feature request: bootload via UART pins ( + reset and Erase )

[ericbaril72]

How tough would it be to use the TX/RX pins of the 0.100" header ?
I could possibly supply you with something

do you have suggestions ? I would look into it to avoid requiring wires between my raspberry pi "HAT" / DUE shield interface.
I would love to finally be able to "Give back" with all the librariries I have been enjoying for a long time.

My understanding:

• the "1200 baud / reset-erase" would need to be adjusted to use RasPI GPIOs
• Device detection would need to be different ( possibly not available )
  I think those parameters are part of the USB implementation of the 16u4 programming interface
  and the USB native interface. Any comments would be appreciated.
• pretty much every other functions would be re-used as-is since they are all part of the "bootloader" inside the SAM3X.
• reset signal would need to be triggered via the 16u4 ( new firmware ) and it's corresponding ICSP1 connetor ( or other suggestion from you )

looking forward to hear from you

[johngrantuk]

Hi Eric,
I think this may work as is but I'm not set up to test at the moment. If you had access to the hardware I'd recommend doing a quick test - 1) Without the Arduino connected run ls /dev/tty* and note the connected devices. 2) Connect Arduino via GPIO serial. 3) Run ls /dev/tty* again and I think it should now show the Arduino port connected. 4) Use the new port to run PiUpDue.
Would be interested to know how you get on.
Cheers,
John

[ericbaril72]

I do have the setup and did go trough piupdue code to run a few functions "manually"
piupdue.GetConnectedDeviceList --> calls GetPortInfo
GetPortInfo runs unix command udevadm
which only reports back on USB interface

Native USB vs programming port USB:
using piupdue the standard way only seems to support native USB but would not require much to support the programming port. ( IF clause in def ArduinoFlashLoad(SketchFile, DueSerialPort, IsNativePort): ) il'll be happy to supply it once I manage to update via the programming port ( not required in my project )

My many DUE's programming port have "ID_MODEL_ID=003d" instead of the required "03e" of piupdue, tried it with 003d but did not succeed. Native USB works very well.

today, i tried to update the 16u2 of my DUE.
ID-MODEL still not showing 003e ...

Once Sam-BA has been triggered, this is where i think the standard UART0 can be used.

Sam-BA prototocol is a bit of a hefty beast to read from scratch... would you know of a few commands i can manually forge to make sure It is active ? anything we can do before toggling to BinaryMode (easier debugging)?
piupdue assumes it is in sam-ba after toggling the 1200baud erase trick.

I have routed my PCB to connect the DUE with my PI and data gets exchanged quite nicely. The Due manages the shutdown of the PI hen the battery gets LOW as I have had a few SDcard corruptions when the PI doesn't go trough a nice shutdown sequence before unpower.

Thanks for you help on it.

I'll be glad to propose a merge if I can it up and running

[ericbaril72]

Now I know what the close button does ...
Any feedback from you John will be appreciated

[johngrantuk]

Hi Eric,
Apologies in the delay getting back to you, got a lot on at the moment. Looks like you are making decent progress with the changes you need.

Port Detection:
I see what you mean about using the command udevadm. When you had the test connected via GPIO could you see the due connected when you ran ls /dev/tty*?

Native USB vs programming port USB:
It feels like I have a memory of successfully using piupdue via the programming port but I can't say for sure. Sounds like your suggested change would be a good way to confirm the functionality.

Sam-BA prototocol active check:
I couldn't find any reliable software method to confirm Sam-BA is active. When I was debugging I usually had whatever program running on the Due flash an LED, when Sam-BA was triggered then the LED would stop flashing and I'd know it was in that mode. When testing reprogramming I usually had the LED altering between a fast and a slow on/off for various programs so I could visually tell when the reprogram was successful. Not very hi-tech but it worked for me!

Hope some of this helps. Let me know if there's anything else.
John

[ericbaril72]

Hello John, thanks for your feedback, I fully understand about being busy on new endeavours.
Any type of support is always appreciated.

For my normal operation mode, I do use /tty/AMA0 on the raspberry pi to communicate with the Arduino DUE. Raspberry pi reads the serial data, parses it and stores it in Database for later upload on my Cloud Server whenever it is Available. GOAL : Only use the arduino DUE headers to avoid wiring. I am using a Raspberry PI HAT/Arduino shield PCB design ( of my own )

For Arduino Update, I have been able to update the arduino using PIUPDUE and a USB cable from the PI to the arduino's native USB. and YES I did try it out with the Blinking LED too :-)
I mixed the Blink_Led example with the Serial comm Port ASCII_table.
When the upload is done via the USB cable, I start seing the LED flashing again and my Raspberry pi Application starts receiveing the ASCII_table again.

updating the DUE has 2 main steps:
1- Put the device in SAM-BA mode
I'll address once I can program a DUE allready in Sam-BA mode ( using the erase button )
2- Upload the New code using the sam-ba protocol

2- UPLOAD (The hardest part ....)
Once the DUE is in SAM-BA mode.
Figure out HOW to detect if the sam-ba mode is active/responding
If it is, call standard PIUPDUE upload routine.

QUESTION: Does SAM-BA bootloader(hardcoded in SAM3X )listens on multiple ports ?
how does it know if the bootload stream is coming from the USB native serial ? OR coming from RX/TX from the 16u2 ? I think so going trough this document that tells us to use the SAM-BA application ( not much on the protocol handshaking SAM-BA)

While on the raspberry PI /dev/ttyAMA0 @ 115200 baud, I can see the programming stream of the arduino IDE, I can also see the answer from the DUE ( swapping the RX signal of the PI from DUE rx to tx )

If Only I could PING SAMBA to see it is alive...
I Saw that "V" or "V#" should tell me which version of samba is running but should V be sent in binary/ ASCII/ HEX is nowhere to be found ... or maybe I search like my daughter.

Would you have some advice on this one ?

Finally, I Keep this one for last : ( this one will be easy )
To put in SAM-BA mode, theese are the current methods ( that I know of )
1 - 1200 baud on native port ( no header pins access, requires external USB cable )
2- 1200 baud on the programming port ( no header pins access, requires external USB cable )
3- Push the erase button a few seconds ( no header pins on the erase signal, just the reset )

Theese are the possibilitites i've identified to put into Sam-BA mode
1- New firmware into the 16u2
1.1- since SAM3X and 16u2 share the same TX signal ( Due RX and 16u2 rx )
a special caracter string would call the standard 1200baud routine of the 16u2
( Standard Arduino peripheral headers )
1.2- Use the ICSP1 header to Signal the 16u2 to execute the 1200baud routine
Easy to do once I figure out the proper way of compiling the USB code for the 16u2.
I was able to update it, but it seems I may have changed the USB "device type" ID and the Arduino IDE no longer recognize the DUE programming port ( wrong ID ? )

[johngrantuk]

Hey Eric,
Wrg to your question about the SAM-BA bootloader(hardcoded in SAM3X )listens on multiple ports? - I'm not actually sure but I think it will. I would just experiment if required.

Wrg to pinging the SAMBA to see if it's alive the "V" idea seems like a good one. An easy check would be to put the Due into SAMBA mode manually then open up a minicom on the PI and enter the "V" command manually and check what the Due replies with. Using something like: sudo minicom -b 115200 -o -D "/dev/ttyACM0"

Hope you get it going!