News:

PROTON pic BASIC Compilers for PIC, PIC24, dsPIC33

Main Menu

FREELOADER

Started by JonW, Sep 20, 2026, 08:03 PM

Previous topic - Next topic

JonW

#40
I am looking at this now

Jx ;D

JonW

HI PEPE

Try this
Config_Start
    PLLDIV  = 5                            ' <-- 20 MHz crystal (table above)
    CPUDIV  = OSC1_PLL2                    ' 96 MHz PLL / 2 = 48 MHz CPU
    USBDIV  = 2                            ' USB clock from the 96 MHz PLL / 2
    FOSC    = HSPLL_HS                    ' crystal, PLL on
    FCMEN    = OFF
    IESO    = OFF
    PWRT    = On
    BOR      = On
    BORV    = 1                            ' about 4.3 V: the 18F part needs 4.2 V+ at 48 MHz
                                            ' (18LF part on 3.3 V: BORV = 2, 2.8 V - and check its max clock)
    VREGEN  = On                          ' USB 3.3 V regulator (needs VUSB cap) - harmless without USB
    WDT      = OFF                          ' no Clrwdt anywhere in mwboot
    WDTPS    = 32768
    MCLRE    = On
    LPT1OSC  = OFF
    PBADEN  = OFF                          ' PORTB digital at reset
    CCP2MX  = On
    STVREN  = On
    LVP      = OFF
    XINST    = OFF
    Debug    = OFF
    Cp0      = OFF
    CP1      = OFF
    CP2      = OFF
    CP3      = OFF                          ' not on the 2455/4455 (24 KB) - delete this line there
    CPB      = OFF
    CPD      = OFF
    WRT0    = OFF
    WRT1    = OFF
    WRT2    = OFF
    WRT3    = OFF                          ' not on the 2455/4455
    WRTC    = OFF
    WRTB    = OFF
    WRTD    = OFF
    EBTR0    = OFF
    EBTR1    = OFF
    EBTR2    = OFF
    EBTR3    = OFF                          ' not on the 2455/4455
    EBTRB    = OFF
Config_End


JonW

OKMN

Try This
Config_Start
    FEXTOSC  = OFF
    RSTOSC   = HFINTOSC_64MHZ               ' short form (the Q43 .ppi long form failed)
    CLKOUTEN = OFF
    PR1WAY   = OFF
    BBEN     = OFF
    CSWEN    = On
    FCMEN    = OFF
    FCMENP   = OFF
    FCMENS   = OFF
    MCLRE    = EXTMCLR
    PWRTS    = PWRT_64
    MVECEN   = OFF                          ' legacy vectors, as the apps use
    IVT1WAY  = OFF
    LPBOREN  = OFF
    BOREN    = SBORDIS
    BORV     = VBOR_2P45
    ZCD      = OFF
    PPS1WAY  = OFF
    STVREN   = On
    LVP      = On
    Debug    = OFF
    XINST    = OFF
    WDTCPS   = WDTCPS_31
    WDTE     = OFF                          ' no Clrwdt anywhere in mwboot
    WDTCWS   = WDTCWS_7
    WDTCCS   = SC
    SAFSZ    = SAFSZ_NONE
    WRTB     = OFF
    WRTC     = OFF
    WRTD     = OFF
    WRTSAF   = OFF
    WRTAPP   = OFF
    CPD      = OFF
    Cp       = OFF
Config_End

JonW

#43
Pepe, Okmn

Did they work?  I don't have those devices, so I cannot fully test

In addition, please don't remove the license header.

Pepe

No. It throws an error when trying to read the EEPROM after six attempts. The strange thing is that the program writes it successfully and it works if I enable "stand-alone EEPROM" and set the features to $3 instead of $23.

JonW

#45
Hi Pepe

Was this tested in a real device or ISIS?

I ran the hex I posted in my simulator (it emulates the 18F PIC side of the bootloader, so I can test and trace both sides with a serial port bridge).
It works fine, and the EEPROM was written.  All the other bootloaders have been tested the same way: simulated first, then in a physical device. 

Pepe

It probably won't work on ISIS

JonW

Pepe, did you test the hex I posted on a real device?

Pepe


JonW

Ah theres the answer..  Isis cant run it fast enough, so I guess then bootloader is fine.  The upload is synchronised but if the eeprom request is not received in 200ms, 6 times it aborts the eeprom. 

okmn

#50
Quote from: JonW on Oct 01, 2026, 12:39 AMOKMN

Try This
Config_Start
    FEXTOSC  = OFF
    RSTOSC  = HFINTOSC_64MHZ              ' short form (the Q43 .ppi long form failed)
    CLKOUTEN = OFF
    PR1WAY  = OFF
    BBEN    = OFF
    CSWEN    = On
    FCMEN    = OFF
    FCMENP  = OFF
    FCMENS  = OFF
    MCLRE    = EXTMCLR
    PWRTS    = PWRT_64
    MVECEN  = OFF                          ' legacy vectors, as the apps use
    IVT1WAY  = OFF
    LPBOREN  = OFF
    BOREN    = SBORDIS
    BORV    = VBOR_2P45
    ZCD      = OFF
    PPS1WAY  = OFF
    STVREN  = On
    LVP      = On
    Debug    = OFF
    XINST    = OFF
    WDTCPS  = WDTCPS_31
    WDTE    = OFF                          ' no Clrwdt anywhere in mwboot
    WDTCWS  = WDTCWS_7
    WDTCCS  = SC
    SAFSZ    = SAFSZ_NONE
    WRTB    = OFF
    WRTC    = OFF
    WRTD    = OFF
    WRTSAF  = OFF
    WRTAPP  = OFF
    CPD      = OFF
    Cp      = OFF
Config_End
Hi JonW,

You asked if it worked: yes, P56Q71_MWBOOT works on a real PIC18F56Q71. Thank you for building it.

My only board is Microchip's PIC18F56Q71 Curiosity Nano (EV01G21A), so I had to adapt it:

The kit's USB-serial is on RB4/RB5, mwboot uses UART1 on RC6/RC7 → two wires: RC6→RB4 and RB5→RC7.
RC7 is also the kit's LED0, so my test app shows life on an extra LED on RD0.
The kit's USB-serial only passes data while DTR is on (Microchip DS50003481A §3.1.2.4). FREELOADER 1.1 can't do that (see below), so I used a small private test script that keeps DTR on and resets the PIC through the kit's debugger. I won't share it.
What I tested (all PASS):

Bootloader programmed alone → no app → it waits.
Sync U→B, INFO: "MWB", features 0x23, flash 0x10000, slot 0xFCF8, DEVID 0x7760.
Upload of a 3-page app + 8 EEPROM bytes: every page K, EEPROM K, X → K, 0.36 s. App runs.
Reset → bootloader → app again, every time.
R: the whole 64 KB read with R is byte-for-byte the same as the expected image and the same as a debugger read-back. EEPROM reads back right. (Earlier I wrote "R not verified" — my frame had LEN 8; with LEN 0 it works.)
My upload image is identical to your --merge output.
Odd flash address, bad CRC (C), unknown command (?) all handled; the next frame always works.
One small FYI: on this build, R with LEN ≠ 0 gets no reply (your table says L). The parser restarts and the next frame works, so it does no harm.

The one problem — FREELOADER 1.1 on this kit: Your help page says --dtr pulses DTR for ~40 ms and both lines are released when the port opens. On the Curiosity Nano, DTR off = no data at all, so FREELOADER waits at "Reset the board now..." and times out (tried no option, --dtr, --rts, --dtr --rts).

Only if you find it useful: an option to keep DTR on the whole time (no pulse), e.g. --dtr-hold. The reset can then come from the kit's debugger in a second window while FREELOADER waits. If you add it, I'll test FREELOADER on this kit straight away and report back.

Small notes: a Curiosity Nano build on UART2 (RB4/RB5) would need no wires. And users should know that programming the kit the normal way (debugger/IDE) erases the bootloader too.

Your licence: P56Q71_MWBOOT.hex used unmodified. One local copy of your Q43 BLINK test program, adapted to this kit (device, LED pin, a UART line), your header kept. It stays on my PC. Nothing of yours is shared anywhere.

Thanks for FREELOADER! okmn

JonW

Hi okmn,


Great write-up; that's a proper test and the first Q71 on real silicon. Much appreciated.

R with LEN not 0: LEN is the number of data bytes that follow in the request for every command. Your frame said 8 but carried none, so mwboot waited for them, timed out after 50 ms and restarted without a reply. Send 8 dummy bytes with a good CRC, and you'll get the L. I'll make that clearer in the table.

DTR: you're right, FREELOADER releases DTR when it opens the port, so the Curiosity Nano passes nothing. I'll add an option to hold DTR on for the whole session and let you know when it's up.

A UART2 build for the Nano is a bigger job as it means moving to the U2 registers. I'll look at it.

Good point on the debugger erasing the bootloader; I'll add a note.

cheers

Jon

okmn

Hi Jon,

Thanks for the quick reply and the clear explanation.

**LEN:** understood — LEN is the data count for every command. My frames said 8 (later 1) but carried no data, so mwboot waited and restarted. Not a bug; my mistake.

**DTR hold:** great, thank you. As soon as it is up I'll test FREELOADER on this kit (same wires) and report back.

**UART2 build:** no hurry at all — the two wires work fine for testing.

Four short videos of the tests, with English captions:
1. Upload through mwboot (sync, pages, EEPROM, exit, app starts) — 22 s
2. Read-back with R: all 64 KB = expected = debugger read — 25 s
3. FREELOADER 1.1 on the Curiosity Nano: DTR released → no data — 61 s
4. The test app on its own (your Q43 BLINK, adapted), programmed by the debugger — 81 s

cheers
okmn





Pepe

#53
This bootloader for 18f26k22 works by simulating it in Proteus, using a virtual COM port and on the 18f2550 it also works partially because Proteus identifies the chip as 1450 and Freeloader doesn't recognize it Anyone who wants can try it on hardware to see if it's useful.

▲