Open gertvdwalt opened 3 years ago
johnnydrazzi
commented
3 years ago Yeah it's possible, but less straight forward to design and use.. Will have to make sure the bootloader always writes the goto (to the bootloader) in the first instruction when programming user code. You would also need to make sure that the first instruction in the user code never occupies the first memory location (location of goto).. I don't really see any benefit to placing the bootloader at the end of memory.
johnnydrazzi
commented
3 years ago I originally thought to write it that way, but then realized it's less safe. If the first goto instruction get's corrupted (it's possible because user code is written to in this area) you won't be able to get to the bootloader.. With the bootloader and goto instruction in the same page/memory region, you can write protect the region.
gertvdwalt
commented
3 years ago The compiler that I use does have the facility to specify that a bootloader is being used by setting the code offset by two instuctions the same way you specify code for your bootloader must be at offset 0x200. It is a relatively old technology compiler and catches a hissy fit if the first page is not accessible. More modern compilers don't mind but I cannot afford them... it might make your bootloader more legacy compatible and will help me quite a lot. Thanks for the reply
On Wed, Aug 4, 2021 at 4:07 AM John Izzard @.***> wrote:
I originally thought to write it that way, but then realized it's less safe. If the first goto instruction get's corrupted (it's possible because user code is written to in this area) you won't be able to get to the bootloader.. With the bootloader and goto instruction in the same page/memory region, you can write protect the region.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/johnnydrazzi/USB-uC/issues/1#issuecomment-892301982, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJNREXWU6HGIF2QJMW4YY23T3COF3ANCNFSM5BPNFKVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
johnnydrazzi
commented
3 years ago The bootloader can fit with the first goto instruction inside the first page (0x800). This is the main reason I rewrote the bootloader in assembly. The GreatCowBASIC compiler has the same limitation as you mentioned and I wanted it to work with it.. In the config.inc file you can remove features to save on space and then play around with the USER_PROGRAM value (user code start location) to make the bootloader as small as possible.. An example I just tried: if you disable the "about file" feature, and set BOARD_VERSION to GENERAL, USER_PROGRAM can be set to 0x780.. Give that a try.
gertvdwalt
commented
3 years ago The compiler I am using happens to be Great Cow BASIC, but in my tests (with the offset set at 0x780) it only compiles very small programs ( like a few lines) and anything substantial it mouns about creating more subroutines and such. Can we negotiate a custom implementation to suit my needs? Since you already give this away for free I cannot presume that you would make modifications just for me for nothing. (unless you want to...). And you may release the result as open source too. Thank you for your time.
On Wed, Aug 4, 2021 at 8:15 AM John Izzard @.***> wrote:
The bootloader can fit with the first goto instruction inside the first page (0x800). This is the main reason I rewrote the bootloader in assembly. The GreatCowBASIC compiler has the same limitation as you mentioned and I wanted it to work with it.. In the config.inc file you can remove features to save on space and then play around with the USER_PROGRAM value (user code start location) to make the bootloader as small as possible.. An example I just tried: if you disable the "about file" feature, and set BOARD_VERSION to GENERAL, USER_PROGRAM can be set to 0x780.. Give that a try.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/johnnydrazzi/USB-uC/issues/1#issuecomment-892394153, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJNREXQ7YE5WYIFLOYBITGTT3DLJHANCNFSM5BPNFKVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
johnnydrazzi
commented
3 years ago When I tested with great cow basic a while back, it seemed to work fine. Maybe my test program was short. It's takes a lot of effort and time making/modifying this assembly version. I'll see if I can reproduce this issue when I get the time. Cheers, John.
gertvdwalt
commented
3 years ago Actually, If it is possible to move the c version to the last page it will also work, since the problem with the first page being full will be solved anyway. Thank you for answering my questions. Really appreciated
On Thu, Aug 5, 2021 at 7:54 AM John Izzard @.***> wrote:
When I tested with great cow basic a while back, it seemed to work fine. Maybe my test program was short. It's takes a lot of effort and time making/modifying this assembly version. I'll see if I can reproduce this issue when I get the time. Cheers, John.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/johnnydrazzi/USB-uC/issues/1#issuecomment-893184961, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJNREXXRIJNEESHAHZCXVPLT3IRQ5ANCNFSM5BPNFKVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
johnnydrazzi
commented
1 year ago @gertvdwalt Hey, I've just started working on this problem, can you please explain how moving the bootloader to the last page in memory helps? As I understand it, the #option Bootloader 0xABC moves the user code by an offset of ABC (interrupts also moved by offset, address of user interrupt 0xABC + 0x4). If the bootloader is small enough to fit in the first page with the beginning of user code, GCB shouldn't complain right? In theory, this shouldn't be different to adding an offset to the user code by 0x8 to leave space for a pagesel and goto at both the reset vector and interrupt vector, which is needed for the legacy bootloader method?
johnnydrazzi
commented
1 year ago I have replicated the issue. Main function and interrupt routine must fit entirely in page 1 for GCB compiler. If the offset is 0x780 for example, your main code and interrupts need to be smaller than 0x80 to fit within page 1. I'll work on making a bootloader version where the bootloader is at end of flash.
gertvdwalt
commented
1 year ago Thank you. I also noted you updated the number of supported pics, good work.
On Tue, Apr 25, 2023 at 4:03 AM John Izzard @.***> wrote:
I have replicated the issue. Main function and interrupt routine must fit entirely in page 1 for GCB compiler. If the offset is 0x780 for example, your main code and interrupts need to be smaller than 0x80 to fit within page 1. I'll work on making a bootloader version where the bootloader is at end of flash.
— Reply to this email directly, view it on GitHub https://github.com/johnnydrazzi/USB-uC/issues/1#issuecomment-1521052177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJNREXTBNEUYOV3VV6XPQBDXC4WILANCNFSM5BPNFKVQ . You are receiving this because you were mentioned.Message ID: @.***>
Would it be possible to move the .asm bootloader for the 16f parts to the last page of memory like the more old school "traditional" bootloaders? essentially with a "goto" in the first instruction.