Hello, I am using the 18F_Family15_TBL_REV6 bootloader, and I've noticed something odd...I program the BL onto the device via MPLAB IPE; works. The first instruction at Address 0 is "Goto 0x1FF00" and indeed, there is the bootloader code ... at address 1ff00 ... when I load a simple "Blink" program via the Tiny Bootloader version 0.14.6.5; the application gets loaded successfully, and just "above' the bootloader where I'd expect it. However, there is now JUNK data starting at address 0x80 for 256 bytes ... the Tinybootloader does load from 0x00 - 0x7E ... but there is no indication of data being loaded into 0x80 or onwards, but there is tones of junk code in there. I've repeated this with clean loads of the Bootloader, erasing the chip, etc...every time I upload code VIA the bootloader, this junk is dropped at 0x80.
Any Ideas?
I'm concerned a bigger program will "Leak" more junk into addresses that may matter at some point.
Okay, as a follow-up, I have identified the issue and have a work-around … not an ideal work-around, but I feel the Windows TMBL application will need to be updated for a full fix.
The Problem: The PIC18F27Q43 (and other Q-models devices) have a 128-word Page Erase and 128-Word page-write capability.
The Code I was using (18F_Family15_TBL_REV6) uses $2F as a chip identifier … I have been working on converting one of the Dan Tinybuilds to work with an 18F27Q43, and so I used the same identifier ($2F).
The $2F chip has a Transfer block size of 128 BYTES (not Words) and this is part of the rub. The JUNK code I was seeing was a result of the internal buffer only being filled 50% (128 bytes vs. 256) and then the entire 256 bytes being written in a page-write operation. MCHIP RAM doesn’t come up in a pre-defined state, so can be anything at power-up.
After the first page-write, the Table-erase routine is called, and all 256 bytes of the buffer ram are written to $FF…subsequent writes are okay since the buffer is routinely being reset. However, you can’t reset the buffer every write-cycle, because you’re only writing half a page at a time, so you’d effectively erase the writes from Cycle 1 on the Cycle 2 write.
Ideal Solution: Allow the windows application to use “256” as a transfer block size number in PICCODES.ini. However, when I set this, transfers fail, and it appears the application doesn’t like the 256 value (is that a single Byte in computer memory?!) Before a transfer, it says the block size is “00” and then tanks. (Note, I also modified the bootloader to accept two bytes for the transfer block size, so the problem is on the Windows app).
Since we can’t send the ideal 256 bytes, we need to send in chunks of 128.
My work-around is:
1: Call the table-erase routine before jumping into the main-loop. This “formats” the RAM buffer to $FF
2: Receive 128 bytes and write them to Flash
3: Check the TBLPTRL value; is it zero? If not, jump back to the main-loop to pull in the NEXT 128 bytes. This leaves the first half of the buffer intact and fills up the second half with the next 128 bytes.
4: Write the page to flash.
5: Check the TBLPTRL value, it’s now zero (128 +128 = 256, so rolled-over to zero).
6: Call the table-erase routine to “format” the RAM buffer to $FF
7: Wash-rinse-repeat
The down-side to my work-around is: For any page that needs the “upper” and “Lower” half written, you’ll be Erasing / Writing that page twice. Frankly, this isn’t too much of an issue for me. It takes more time to transfer code (but that’s not a concern for me) and basically, rather than the chip being “guaranteed” for 10,000 programming cycles, it’s now only guaranteed for 5,000 programming cycles. I can live with that … if I have to change my code 5000 times, I have other issues!
Still, I’ll continue to noodle on a way to prevent the double-write from the chip-side … and I’d like to see my ‘ideal solution’ implemented on the application so we can send the actual number of bytes to the chip that it’s capable of handling.
But, as things sit now: I have a functional Tiny Multi Bootloader for the 18F27Q43 chip that works as expected!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I posted my HEX in the other thread...and again, it works, but it's double-writing pages. If the PC application doesn't send 256 bytes per block...unless you've written some logic into your BL firmware to check for both 128B 'chunks' before writing a page? But in my testing, the first page written (0x00) is just 128B, as it's just updating the 0x00 instruction to launch the BL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, I am using the 18F_Family15_TBL_REV6 bootloader, and I've noticed something odd...I program the BL onto the device via MPLAB IPE; works. The first instruction at Address 0 is "Goto 0x1FF00" and indeed, there is the bootloader code ... at address 1ff00 ... when I load a simple "Blink" program via the Tiny Bootloader version 0.14.6.5; the application gets loaded successfully, and just "above' the bootloader where I'd expect it. However, there is now JUNK data starting at address 0x80 for 256 bytes ... the Tinybootloader does load from 0x00 - 0x7E ... but there is no indication of data being loaded into 0x80 or onwards, but there is tones of junk code in there. I've repeated this with clean loads of the Bootloader, erasing the chip, etc...every time I upload code VIA the bootloader, this junk is dropped at 0x80.
Any Ideas?
I'm concerned a bigger program will "Leak" more junk into addresses that may matter at some point.
Screenshots can be found here...
Thanks!
Bill is aware. I have sent him this URL.
Okay, as a follow-up, I have identified the issue and have a work-around … not an ideal work-around, but I feel the Windows TMBL application will need to be updated for a full fix.
The Problem: The PIC18F27Q43 (and other Q-models devices) have a 128-word Page Erase and 128-Word page-write capability.
The Code I was using (18F_Family15_TBL_REV6) uses $2F as a chip identifier … I have been working on converting one of the Dan Tinybuilds to work with an 18F27Q43, and so I used the same identifier ($2F).
The $2F chip has a Transfer block size of 128 BYTES (not Words) and this is part of the rub. The JUNK code I was seeing was a result of the internal buffer only being filled 50% (128 bytes vs. 256) and then the entire 256 bytes being written in a page-write operation. MCHIP RAM doesn’t come up in a pre-defined state, so can be anything at power-up.
After the first page-write, the Table-erase routine is called, and all 256 bytes of the buffer ram are written to $FF…subsequent writes are okay since the buffer is routinely being reset. However, you can’t reset the buffer every write-cycle, because you’re only writing half a page at a time, so you’d effectively erase the writes from Cycle 1 on the Cycle 2 write.
Ideal Solution: Allow the windows application to use “256” as a transfer block size number in PICCODES.ini. However, when I set this, transfers fail, and it appears the application doesn’t like the 256 value (is that a single Byte in computer memory?!) Before a transfer, it says the block size is “00” and then tanks. (Note, I also modified the bootloader to accept two bytes for the transfer block size, so the problem is on the Windows app).
Since we can’t send the ideal 256 bytes, we need to send in chunks of 128.
My work-around is:
1: Call the table-erase routine before jumping into the main-loop. This “formats” the RAM buffer to $FF
2: Receive 128 bytes and write them to Flash
3: Check the TBLPTRL value; is it zero? If not, jump back to the main-loop to pull in the NEXT 128 bytes. This leaves the first half of the buffer intact and fills up the second half with the next 128 bytes.
4: Write the page to flash.
5: Check the TBLPTRL value, it’s now zero (128 +128 = 256, so rolled-over to zero).
6: Call the table-erase routine to “format” the RAM buffer to $FF
7: Wash-rinse-repeat
The down-side to my work-around is: For any page that needs the “upper” and “Lower” half written, you’ll be Erasing / Writing that page twice. Frankly, this isn’t too much of an issue for me. It takes more time to transfer code (but that’s not a concern for me) and basically, rather than the chip being “guaranteed” for 10,000 programming cycles, it’s now only guaranteed for 5,000 programming cycles. I can live with that … if I have to change my code 5000 times, I have other issues!
Still, I’ll continue to noodle on a way to prevent the double-write from the chip-side … and I’d like to see my ‘ideal solution’ implemented on the application so we can send the actual number of bytes to the chip that it’s capable of handling.
But, as things sit now: I have a functional Tiny Multi Bootloader for the 18F27Q43 chip that works as expected!
We have totally rewritten the TBL auto tooling for the Q43. The issue may not exist in the new TBL code. Send me your HEX and let me test.
I posted my HEX in the other thread...and again, it works, but it's double-writing pages. If the PC application doesn't send 256 bytes per block...unless you've written some logic into your BL firmware to check for both 128B 'chunks' before writing a page? But in my testing, the first page written (0x00) is just 128B, as it's just updating the 0x00 instruction to launch the BL.
The new TBL does clear the buffer. I have emailed Bill to get his attention.