It's not a huge program - it takes up about 18KB, but the program memory listing in PicKit3+ shows it starting at 0000 and ending at about 18E0 . If this is its true location, then the first few bytes of the bootloader at 0000, are overwritten by it. I can certainly try the option reserve.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm using the TMBL+ as the programmer when loading the firmware. That loads OK and the board works OK. However, if I now try to re-load the firmware with TMBL+, it can't detect the device. Re-loading the bootloader fixes this. I am assuming that the failure is because the firmware overwrites something in the bootloader code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is the DTR/RTS reset working as expected for you? Power cycle the board when it try to program. If a power cycle works then the DTR/RTS reset is not operating as you need.
If the TBL bootloader is recognised by the application once ( that is after loading the TBL firmware). Therefore, no user program (at this stage) then the communication lines are go.
If the TBL application writes and the program 'does something that is should' then the 'send and write operations' are good.
At this stage - if the TBL application does not respond but 1 ) it is recognised with a power cycle - this the reset circuit or the MLCR is not working as expected. 2) it not recognised then it is a fatal error in the firmware.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is a bootloader available for the 18F16Q40 range of chips? I believe that one was under development a couple of months ago.
Thanks!
Terry
I am working the code today. I may have something to test tomorrow.
I will use the Q40. I was testing with the K83.
Hi Anobium - that's great to know. Thanks!
Working - the process now supports all the new chips from Microchip including 18FxxQxx, 18FxxK83 and 18FxxK84 etc.
The video shows the result of a lot of development effort.
.Last edit: Anobium 2023-05-12
Impressive - it looks good!
Send me an email or a PM. The release is ready. There may be some configuration or specifics you need.
I have had this on my backlog for a while. I am happy that I was able to complete the project.
Hi Anobium,
The bootloader is working fine, but my program overwrites the bootloader when it is loaded. How can this be avoided?
Thanks,
Terry
What development IDE/Toolchain are you using?
I'm building it in GC Studio and using PicKit3+ with the board.
GCBASIC is generating a program that fills the PROGMEM? That is a big program.
If you writing direct to PROGMEM using PFMWrite or Poke() then you need to ensure the addresses are not within the range of the bootloader.
Check the ASM to see is any of the datatables are in the last few pages of PROGMEM ( bootloader lives there!).
Try adding: #OPTION RESERVEHIGHPROG 512 - this will instruction GCBASIC to reserve the top of PROGMEM.
It's not a huge program - it takes up about 18KB, but the program memory listing in PicKit3+ shows it starting at 0000 and ending at about 18E0 . If this is its true location, then the first few bytes of the bootloader at 0000, are overwritten by it. I can certainly try the option reserve.
You are using TBL+ programmer from the IDE not PK+? You need to use TBL+ as the programmer.
I'm using the TMBL+ as the programmer when loading the firmware. That loads OK and the board works OK. However, if I now try to re-load the firmware with TMBL+, it can't detect the device. Re-loading the bootloader fixes this. I am assuming that the failure is because the firmware overwrites something in the bootloader code.
The TBL+ application relocates the 0x0000 jump vector to the correct address for your chip. So, I know that works, as it works here.
What is your program ? attach to a post. Maybe something in that is cause.
OK - here is the current version
Nothing obvious jumps out. Try something simple. Led on/off ' does that work? Then, buildup from that to isolate the issue.
Works here.
Is the DTR/RTS reset working as expected for you? Power cycle the board when it try to program. If a power cycle works then the DTR/RTS reset is not operating as you need.
OK - that's the problem. My tiny surface mount joint to the RTS pad was bad. Many thanks for the suggestion!
I have learnt.
If the TBL bootloader is recognised by the application once ( that is after loading the TBL firmware). Therefore, no user program (at this stage) then the communication lines are go.
If the TBL application writes and the program 'does something that is should' then the 'send and write operations' are good.
At this stage - if the TBL application does not respond but 1 ) it is recognised with a power cycle - this the reset circuit or the MLCR is not working as expected. 2) it not recognised then it is a fatal error in the firmware.