e3efe04836
Have basic testing complete of erasing application/main code, flashing data, and reading it back for verification. This ended up being pretty big task to get working. Some previous efforts helped out quite a bit though. The first thing needed was a path out of the main application and this was done in bootload.c by calling PREP_FWUPDATE. That jumps to the fwupdate area (first 2KByte) of flash. There the 'fwupate main' takes over. It updates the usbFunction Setup/Write ram function pointers to fwupdate's own setup function. Then it must hijack the processor's execution so once the PREP_UPDATE exception is complete the processor returns to the fwupdater instead of the main. This is done by snooping back through the stack and finding the stack frame keying off of xPSR and valid PC address. It then stomps the PC & LR in the stack frame to steal execution from the main thread. After that, all usb transfers are handled by the fwupdater. Able to get buy without the write so far since setup packets provide data but are also IN transfers to give path for sending data back to host. So to keep things small and simple this is all that's handled so far. Once I get tired of it being so slow I can implement the usbFunctionWrite and speed things up quite a bit. Haven't actually timed it yet, but for only 20KByte of data it and not being very frequent it shouldn't be a big deal. The more I say this the more I'm thinking I'll add that next because I'll be using it myself so much for development.. Less time in that state is less likely for ppl to 'semi-brick' their device. There is of course always the stmicro dfuse demo that can always unbrick the device. I tried really hard to jump to their bootloader but no matter what I did I couldn't get it working. It was never recognized by USB. I half way wonder now if I needed to disable the bootpin which I never would want to do anyway.. Created separate build_stm folders for INL6 & INL_NES which is what all the NESmaker kits use. Also update the make files to be more accurate about what chip their using since fwupdate tries to prevent a hardfault from flash access beyond what's available. This update doesn't include a means of updating the first 2KByte of firmware updater space itself. But the application code should be able to take care of that for us in a future update. It's only 2KByte so just temporarily storing the fresh build in SRAM will probably work. Although will have to be careful about any calls from application code to fwupdater. Plus there's always dfuse.. Other problem I ran into was erasing the application code. It worked fine early on for all 30KByte. But as my fwupdater function grew it crashed when page 18 was erased. Realized my bigger switch/case statement was calling a gcc library function that resided in the application code. It was only 50Bytes, so moved it to fwupdate section. Brought 2 of similar library functions over as well, but one of them disappeared with update to latest version of arm-none-eabi-gcc. Not a commit really, but this is the release where I updated gcc. Was previously: gcc version 6.2.1 20161205 (release) [ARM/embedded-6-branch revision 243739] is now: gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update) Updating gcc provided a smaller build size of ~250 Bytes from the tail end. But it also freed up ~50Bytes in fwupdate space as well. |
||
|---|---|---|
| .. | ||
| include | ||
| scripts | ||
| source | ||
| udev-rule-help | ||
| winlib | ||
| Makefile | ||
| inlretro.exe | ||
| inlretro_commited.exe | ||
| libusb-1.0.dll | ||