There are two hex-files for DuinoMite-Mini on https://github.com/OLIMEX/DuinoMite/tree/master/SOFTWARE/FIRMWARE:
DuinoMite-Mega-Mini_Bootloader+DMBasic.hex
DuinoMite-Mega-Mini_ONLY_DMBasic.hex
What hex-file should I flash if I want to have a HID bootloader for future use? I now think the file with bootloader is the right to use. Is this correct?
I usually use Universal Bootloader v1.1 (BootLoader.exe) in Windows 10 x64.
USB Bootloader v2.90a - For Olimex Boards https://github.com/OLIMEX/DuinoMite/tree/master/SOFTWARE/HID-BOOTLOADER also worked, but then I got some errors about PEEK each time I reset DMBasic. I didn't get these errors with Universal Bootloader v1.1.
(I had some other issues before, but that was because I downloaded files using right click instead of raw or download. Using right click you get a web page.)
I don't have the experience of HIDBootLoader.exe under Windows 10. It works correctly in the old Windows XP which I still use to update my Duinomites.
But anyway, if you don't have a correct bootloader installed on the Duinomite, it is not possible to load a correct Basic to it, neither 2.7 nor 4.5.
Kees
But I have a correct bootloader on my old DuinoMite-Mini -- it's my new DuinoMite (mentioned in other thread) that doesn't have a bootloader.
Use DuinoMite-Mega-Mini_ONLY_DMBasic.hex
You can't overwrite the bootloader via the bootloader. So you can't upload DuinoMite-Mega-Mini_Bootloader+DMBasic.hex via the USB, it is meant to be programmed via a programmer.
There is some more info at the bottom here: https://github.com/OLIMEX/DuinoMite/tree/master/SOFTWARE
I actually did flash my old DuinoMite-Mini with DuinoMite-Mega-Mini_Bootloader+DMBasic.hex using USB and Universal Bootloader v1.1. It worked without problem, and then I flashed some other hex-file: OlimexDuinomiteMiniTRS80.hex and that also works well. I had the OlimexDuinomiteMiniTRS80.hex on before I flashed DuinoMite-Mega-Mini_Bootloader+DMBasic.hex so I know none of the files destroy the bootloader when using Universal Bootloader v1.1.
This is odd. You are saying that you overwrite the code, which you are executing at that moment. I don't know how the flashing process is actually done by the PIC32 controller, but it seems to me that it is very tricky (in fact impossible) to change memory locations while executing code from them.
Probably the software is smart enough and ignores the parts in the binary that are impossible to write over. Writes just the in memory ranges that it has access too.
Clarification: I mean probably the software ignores errors and warnings when it can't write to a locked address (where the bootloader is located) so it ends up writing only the non-bootloader-related part of the binary anyway.
But what if the code you are using has to be changed? I see this as a masturbating process; it can be very nice, but it will not generate new children :)
The code can run from RAM and rewrite any flash area, if it wishes.
Whether the one you refer to does that - read the code? (I don't think I have it but in any case have several PIC32 programmers including a Raspberry Pi.)
John
OK John, I agree that the code can be copied to RAM and run from there. But this will stay very tricky, because if the flashing of the bootloader goes wrong, the unit will be useless without an external programmer after that. In this particular case I think the bootloader has been corrupted and that is the reason it does not work anymore.
BTW as far as I know the used bootloader is not "open source". Some years ago I had to change the configuration bits of the Duinomite eMEGA and could arrange this only by changing the HEX-code (also with your help, thanks again)
Any time you replace the bootloader using the board itself to do it is a risk, yes.
(I don't think the actual DM bootloader ever rewrites the boot flash, though. Would be good to have the source to check that.)
An external device (PICkit or whatever) can always recover the situation. Not ideal if you need to do this and the board is far away or some such but PIC32 does not have a feature such as a backup bootloader (most uC chips also do not) the way many PC mobos do.
It's why generally with this sort of bootloader you try to program it just once :)
(i.e. at the factory)
Having said that most uC chips also do not have a backup bootloader, some do have a sort of equivalent. E.g. the Allwinner chips hunt around for something to boot and may be more suitable for some uses.
John