hex won't work on pic10f200

Quote from robot.pizza on August 5, 2025, 4:41 amWhy won't it work? This same hex file works fine on the hardware and in MPLAB.
Starting Circuit Simulation...
Loading hex file:
C:/Users/dadof/blinker/build_blinker/blinker.hex
Warning: PGM End reached at Line 7
Address: 0xfff > PMG End: 0xFF
TODO: Config word ??
Firmware successfully loaded
Simulation Running...
eMcu::stepCpu: Error PC = 256 PGM size = 256
MCU stopped
Why won't it work? This same hex file works fine on the hardware and in MPLAB.
Starting Circuit Simulation...
Loading hex file:
C:/Users/dadof/blinker/build_blinker/blinker.hex
Warning: PGM End reached at Line 7
Address: 0xfff > PMG End: 0xFF
TODO: Config word ??
Firmware successfully loaded
Simulation Running...
eMcu::stepCpu: Error PC = 256 PGM size = 256
MCU stopped

Quote from robot.pizza on August 5, 2025, 6:08 amLooking a little further, I see it hits the addr > dataEnd condition in memdata.cpp:192
This means that it thinks the address is beyond the end of data?
Much more research later, and I find out the following... indeed, this IS the config word just as the TODO output says. The loader should either use the config word, or ignore lines with 1FFE address when loading to PIC10F200. Please fix. For now, I guess I have no choice but to add a build step that removes the line with address 1FFE from the hex output.
: 10 0000 00 0E 0C0600DF0C0200010C3300010C340062
: 10 0010 00 08 0C35000605010C3200010C2809060405
: 10 0020 00 13 023200010C2809F5020A0A080C3500F7
: 10 0030 00 14 02F301FF0CD3014307210A010C340021
: 10 0040 00 0A 0AEC0CD30143070A0AFF0C34000A0A1F
: 10 0050 00 30 0012023100210243072B0AF1022B0A61
: 06 0060 00 F0 02290A00086D
: 02 1FFE 00 EB 0FE7
: 00 0000 01 FF
Looking a little further, I see it hits the addr > dataEnd condition in memdata.cpp:192
This means that it thinks the address is beyond the end of data?
Much more research later, and I find out the following... indeed, this IS the config word just as the TODO output says. The loader should either use the config word, or ignore lines with 1FFE address when loading to PIC10F200. Please fix. For now, I guess I have no choice but to add a build step that removes the line with address 1FFE from the hex output.
: 10 0000 00 0E 0C0600DF0C0200010C3300010C340062
: 10 0010 00 08 0C35000605010C3200010C2809060405
: 10 0020 00 13 023200010C2809F5020A0A080C3500F7
: 10 0030 00 14 02F301FF0CD3014307210A010C340021
: 10 0040 00 0A 0AEC0CD30143070A0AFF0C34000A0A1F
: 10 0050 00 30 0012023100210243072B0AF1022B0A61
: 06 0060 00 F0 02290A00086D
: 02 1FFE 00 EB 0FE7
: 00 0000 01 FF

Quote from arcachofo on August 5, 2025, 12:38 pmHi. Thanks for reporting.
Config Word should not be a problem, I think it must be something else.
I will have a look.
Hi. Thanks for reporting.
Config Word should not be a problem, I think it must be something else.
I will have a look.

Quote from robot.pizza on August 5, 2025, 1:03 pmAgreed, I saw the return true later and realized it should have worked anyway (just before going to sleep).
Update: Yes I tried this removing that line, and while the warning went away it still doesn't work.
Is there any chance the loader assumes the start address is nonzero? By default the linker will choose high addresses. This causes the goto startloop to be lost (won't overwrite oscillator tuning value). I've seen workaround by adding nop at the end, but I fix it by just starting at zero. Perhap this isn't an issue in C, which is probably the test case.
Agreed, I saw the return true later and realized it should have worked anyway (just before going to sleep).
Update: Yes I tried this removing that line, and while the warning went away it still doesn't work.
Is there any chance the loader assumes the start address is nonzero? By default the linker will choose high addresses. This causes the goto startloop to be lost (won't overwrite oscillator tuning value). I've seen workaround by adding nop at the end, but I fix it by just starting at zero. Perhap this isn't an issue in C, which is probably the test case.
