FREELOADER FILE ACCESS

[JonW]

Hi Pepe

I don't have a 2550 yet and posted it there for others to test.  I will try to get hold of one, and in the meantime will take that device off the site and have a look through your code.

They are also designed to work in real devices, synchronised in real time with the bootloader pc application.

[RGV250]

Hi Jon,
I am sure i have some 2550's so if you PM me your address i will post them to you.

Regards,
Bob

[JonW]

Pepe,

I've been through the .bas and .hex you sent. It is my MWBOOT_2550 with your edits: the UART set-up, sync, parser, CRC, flash and EEPROM write code are the release code, unchanged. So if yours "works" and the release "doesn't", the difference is your simulator, not the bootloader.

Header

You have removed my copyright notice again. That is the second time. mwboot is free to use, but the notice stays and modified versions are not to be distributed. Modified copies in circulation confuse other users about which file is the real one. If you have a fix, send it to me and I will fold it into the release with credit.

Bugs in your version

1. cWindowMs 1000. bRxTimeout is a byte, so 1000 becomes 232 (your hex loads 0xE8). Your window is 232 ms, not 1 s.
2. CP0 to CP3 = On. Your hex has CONFIG5L = 0x00, which is code protect on all four blocks. On a real chip a programmer can no longer read it back or verify it, until a bulk erase. I doubt that was intended.
3. cNVM_Idle 0x40. Your comment says CFGS = 0, but 0x40 is CFGS = 1. It only gets away with it because the next operation rewrites EECON1.
4. Your header says slot 0x7CF8, code 0x7D00, 776 bytes reserved. With cBootPages 4 it is slot 0x7BF8, code 0x7C00, 1032 bytes. That is 256 bytes of application space lost for nothing.

The stack

This is the one real point. On a blank part, each window timeout leaves one return address on the stack, so after 31 windows STVREN resets the chip, about every 3 seconds. On silicon, that is a clean reset straight back into the same sync window. It cannot happen once an application is loaded, and it has no effect on an upload because the command loop clears STKPTR on every pass. It is verified harmless on silicon, but for correctness I am clearing STKPTR at the exit in the next release, on every family.

Simulators

What I will not do is change the bootloader's format or structure to satisfy a simulator that does not behave like the chip. Your changes to R (config and ID padded with zeros), the longer window and the 4-page layout are there for ISIS, not for a 2550. The protocol, layout and timing are the same across all families, and that structure is bench-proven on real Q43, K42, K40, K20 and K22 parts. Test on a real 2550 before reporting issues.

Test status

Starting with the next release, every bootloader will be marked either BENCH-PROVEN (run on a real chip) or SIMULATOR ONLY in the file header and in the download. Simulator-only parts stay available for anyone who wants to try them and report back. The 2550 is simulator-only today: I have re-run the release in my simulator (Real time simulator, not ISIS), and it passes, and I will confirm it on a real chip as soon as I have one.



Jon

[Pepe]

Thank you very much for your reply.

[JonW]

Added some more tested devices and a free Serial terminal. MWTERM HERE