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.
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!