Menu

Bootloader for 18F16Q40

2023-05-11
2023-05-15
  • Terry Platt

    Terry Platt - 2023-05-11

    Is a bootloader available for the 18F16Q40 range of chips? I believe that one was under development a couple of months ago.

    Thanks!
    Terry

     
  • Anobium

    Anobium - 2023-05-11

    I am working the code today. I may have something to test tomorrow.

     
  • Anobium

    Anobium - 2023-05-11

    I will use the Q40. I was testing with the K83.

     
  • Terry Platt

    Terry Platt - 2023-05-11

    Hi Anobium - that's great to know. Thanks!

     
  • Anobium

    Anobium - 2023-05-12

    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
  • Terry Platt

    Terry Platt - 2023-05-12

    Impressive - it looks good!

     
  • Anobium

    Anobium - 2023-05-12

    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.

     
  • Terry Platt

    Terry Platt - 2023-05-15

    Hi Anobium,
    The bootloader is working fine, but my program overwrites the bootloader when it is loaded. How can this be avoided?

    Thanks,
    Terry

     
    • Anobium

      Anobium - 2023-05-15

      What development IDE/Toolchain are you using?

       
  • Terry Platt

    Terry Platt - 2023-05-15

    I'm building it in GC Studio and using PicKit3+ with the board.

     
  • Anobium

    Anobium - 2023-05-15

    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.

     
  • Terry Platt

    Terry Platt - 2023-05-15

    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.

     
    • Anobium

      Anobium - 2023-05-15

      You are using TBL+ programmer from the IDE not PK+? You need to use TBL+ as the programmer.

       
  • Terry Platt

    Terry Platt - 2023-05-15

    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.

     
    • Anobium

      Anobium - 2023-05-15

      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.

       
  • Terry Platt

    Terry Platt - 2023-05-15

    OK - here is the current version

     
    • Anobium

      Anobium - 2023-05-15

      Nothing obvious jumps out. Try something simple. Led on/off ' does that work? Then, buildup from that to isolate the issue.

       
  • Anobium

    Anobium - 2023-05-15

    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.

     
  • Terry Platt

    Terry Platt - 2023-05-15

    OK - that's the problem. My tiny surface mount joint to the RTS pad was bad. Many thanks for the suggestion!

     
    • Anobium

      Anobium - 2023-05-15

      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.

       

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.