Gerhard Fiedler wrote: > > What I do looks like this (inside the PIC, nothing PC-side): > > > >> No matter what I try, there will always be a way of generating an >> incompatible reset vector, but I want something that works well with >> most compilers and isn't overly complex to implement > > The one thing that wouldn't work with my scheme is if there is a jump to > one of the first 8 bytes in the application (except 0). But I think this is > quite rare. What about a relative branch to the user code instead of an absolute goto? ORG 0 bra START since bra is relative, it wouldn't work when you relocate then code to the new area. If it weren't for this case I would have already done it the way you suggest. Here's my current idea: The bootloader owns the first 4 bytes (enough space for a goto), though it does copy the full 8 bytes into its private space (this is in case user code decides to jump into any of those instructions), so there would be two copies of the following words. The bootloader private area would look like this: goto 8 goto 10 ; this is in case there's a skip instruction at the end of the user code goto goto goto goto where the last four gotos are space to store the absolute versions of any branches the user code might have in the vector. The branches are modified to point to the gotos, which point to the original target of the branch (this is because branches have a limited target distance, and they also take only 1 word instead of two for goto). I think this should work for most cases (except when user code jumps into the first or second word in program memory). Then, do the exact same thing for the interrupt vector, if requested (the bootloader doesn't need interrupts, but there's an option to use them as a hook for instant re-programming without having to manually reset the board to program mode). > > > Hi-Tech puts some basic context saving code at the interrupt vectors, > followed by a goto. If no interrupt functions are defined, it doesn't > generate any interrupt vector code. The goto that is at the reset vector is > preceded by a nop in some cases (seems to be required by some erratas). Do you have an example handy? (hex or asm) >> For reference, the interrupt hijack function works like this: if the user >> code doesn't use the UART, it can request the bootloader leave >> interrupts enabled and hijack the low vector, and leave the UART >> enabled. The vector in the bootloader code checks for RCIF and receives >> a character. If the character looks like a bootloader init sequence, it >> resets the PIC. Otherwise, it restores registers and jumps back to the >> user vector (it uses a couple hacks to avoid the usage of any RAM at >> all). > > This looks like it might complicate things. Do you really have to redirect > the interrupts? Isn't it enough to check at boot? > > Anyway, if you need to do this, maybe something similar as what I'm doing > with the reset vector works for you. Just extend it to cover the interrupt > vectors. I'm considering this feature experimental, and it's optional (the user code has to include a magic word somewhere indicating it wants this patching done, otherwise it just proceeds normally). The idea is to let people write really simple programs (with no interrupts or only basic interrupts, and no UART use) and automatically patch them to support bootloader resetting via UART (which amounts to hijacking the interrupt vector, just like the reset vector). I think doing the same thing as done for the reset vector should work in this case, though of course I don't expect it to work as far as dealing with the possible things the user code might do with the UART and interrupts - it's only meant for simple cases. I'm using this bootloader mainly for development (which is why doing things PC-side sometimes isn't a problem, as if the bootloader dies I can just reflash the PIC). This bootloader is meant for a workshop I'm setting up for later this year, where people will build and program small robots. I don't have 15 PIC programmers, so I'm embedding a MAX233 into the robot PCB and using a plain serial cable with it. This way, people can quickly try new versions of their code without having to go around loading the software and pressing reset on the PIC every time (it gets very tedious if you make a lot of mistakes in the code!). If for some reason one of them dies (the only case I can think of this might happen, short of modifying the PC software, is when the first block is erased but interrupted before it's programmed), I can easily walk over with my Wisp628 and reflash the bootloader. -- Hector Martin (hector@marcansoft.com) Public Key: http://www.marcansoft.com/marcan.asc -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist