Propeller Hat Checksum Error


Hi there!

So I now bought a Raspberry Pi 2 Model B, installed it via noobs, followed all your setup instructions and actually get a blinkenled to work, if i select “RUN” in PropellerIDE. When I select “BURN”, however, I get a checksum error, and that’s it.
No code being executed.

Something’s clearly wonky. EEPROM Write Protect line active for some weird reason?
If I read the EEPROM contents with i2cdump -y 0 0x50 (i managed to get i2c-0 to work after encountering this problem) I get 256 Bytes containing 0xFF.

I guess that’s all I can tell.

What now?

Thanks and best regards,


And here’s the full solution. The onboard eeprom is for hat compatibility.
There is no onboard eeprom for the propeller. Duh.
However the hat-compatibility-eeprom being blank confused me a bit.
So that’s that…


Sorry! You’re not the first to be confused by this. I’ll have to make the product description a little clearer.

The lack of EEPROM for the Propeller was a conscious choice due to it being paired with the Pi- although there seem to be many who’d prefer it with an EEPROM I didn’t want to push the cost too high.

You can add one yourself really easily ( apart from getting hold of the part itself ) and I’ve been looking into stocking them for just this reason.

The HAT EEPROM definitely shouldn’t be blank though! Not that it’ll make an iota of a difference right now, but reading the HAT data from userspace is available as of Kernel 4.x (if I’m not mistaken) so it’s going to prove useful sooner or later.


Thanks for the reply!
I am a bit embarrassed by this mistake, but for me it proves we all have our weak moments^^
I added a 24lc512 last night, and got the same trouble. I have added decoupling caps. No improvement. I then put the same eeprom on a breadboard with a 40pdip propeller, which threw the same behaviour. So i tried to actually write to the eeprom using the i2c tools, and although it didn’t throw an error, reading it back got me a clean set of FFs. Right now I’m having a grand wtf moment, my dso is at work, and using an LED for debugging isn’t that conclusive. There is something happening on data and clock in all of the described cases. So I’m now left with two eeprom ics, two propellers, a raspberry pi 2b and totally fail to write to these memories big time.

No chance this is anything but my mistake somewhere.


In both cases, have you tied A2, A1, A0 and WP from the 24LC512 to Ground?

Oh and 10K pullups on the Data/Clock ( ducks It’s worth mentioning! )


The address inputs are low, write protect is low, and no need to duck for the pull-ups question. Now as I’m just having dinner in a minute, I can’t tell for sure if it’s clock or the data line, but I have one pull-up of 10k on one of the lines (following the schematic in the manual). Now I am used to put pull-ups on both lines (i2c doesn’t really work without, as it’s open collector based), and to be honest, I don’t know if and where the raspberry pi has pull-ups. Now this may very well mean i have one of the lines floating.
Will check after dinner


Well that didn’t help.
Pull ups on both lines didn’t make it work. I’m going to have a closer look with a logic analyzer tomorrow. This is weird.