Eth bootloader - What does the switch do and topboard Rev 1.6?
This follows an e-mail regarding working with a topboard that is Rev 1.6 where there is no eth bootloader switch.
What exactly does the ethernet switch do?
Are these pads (rev 1.6) default shorted – I wouldn’t think so but they might be?
What I have discovered is I can successfully TFTP if: I issue a reboot and while rebooting (first 3 seconds or show) I immediately issue the put from TFTP and then issue another reboot.
Now the problem is this window is incredibly small; especially for my application.
Is something not quite functioning right (the ethernet bootloader switch would normally do something additionally allowing for the acceptance of a file) or will this always be the case that the controller needs to be in the bootloader state to communicate with the TFTP? If this is the case what is the option to extend that state, modify the bootloader?
Where we are still trying to go (discussed with you briefly last year) is to have a global tftp OTA server.
We are trying to enact your previously suggested solution whereby we:
- Check a website via HTTP if there is an update
- *If there is an update have the server issue a controller reboot (additional step if we have to put it into a bootloader state)
- Have the server do the put from the tftp
- Have the server issue another reboot
If the reality is we need the reboot to get it into a file accepting state from the TFTP you can see how this can become problematic with only a 3 second wait for a new program. Especially since I don’t think there will be any good way for the server to check if the controller is ready for tftp.
For future reference, a summary of our findings:
- On D21G topboard v1.6 the Ethernet bootloader is enabled by default; it can be disabled by cutting a trace and soldering the OFF bridge. topboard v1.7 has a switch.
- When doing the reset of the board by URL, it remains in the bootloader state for a couple of seconds only, so you need to be quick to start the TFTP put. The TFPT on the other hand has a longer timeout, so you can also start the TFTP put, and then perform the board reset by URL. In both cases, only 1 reset is needed. This works well with the Linux CLI tftp command, it has a timeout of around 25 seconds. TFTP on Windows and Mac may behave differently, even refusing the connection as long as the board is not in bootloader mode (thus requiring 2 resets).
- To make sure it is not a network issue that is blocking the TFTP (firewall blocking UDP ports), you can test with a simplified network: an Ethernet cable between laptop and Industruino, with the laptop disconnect from wifi/LAN. Your laptop should be configured with a fixed IP address, e.g. 192.168.1.1, also used as gateway, and mask 255.255.255.0. Just make sure to use a compatible fixed IP address on the Industruino, e.g. 192.168.1.199.
You can have a look at this simple Linux shell script to automate the TFTP transfer (after preparing your file with the prepareFile utility); it resets the board by URL and then immediately starts the TFTP put.
Your answer
Please try to give a substantial answer. If you wanted to comment on the question or answer, just use the commenting tool. Please remember that you can always revise your answers - no need to answer the same question twice. Also, please don't forget to vote - it really helps to select the best questions and answers!
Keep Informed
About This Forum
This community is for professionals and enthusiasts of our products and services.
Read GuidelinesQuestion tools
Stats
| Asked: 1/16/20, 1:12 PM |
| Seen: 1590 times |
| Last updated: 1/28/20, 1:43 AM |