>> Ok, maybe another poke in the dark:
>> There is this thing where page write (= writes > 1B) have to be aligned to 
>> the page size (128B for my chip):
>> […]
>> Maybe that could explain why you would get 0xFF as the second byte?
> Just as a follow-up on this, I just tried this, and it does indeed return 
> 0xFF for the second byte.
> So writing 2B to address 127 on a fresh chip (ie. all memory to 0xFF), will 
> result in this behavior.
> My test code then produces this:
>         {2D, CF} != {2D, FF}
>         {46, 29} != {46, FF}
>         {04, B4} != {04, FF}
>         {78, D8} != {78, FF}
> Is that what you are seeing?

It has nothing to do with this, I'm not even close to the page
boundaries. I'm trying to write and read the first ~4 bytes. I've
tried a million things now without much success. One thing I do which
I know I shouldn't is using RF_CALL_BLOCKING everywhere. Could this be
the cause?

xpcc-dev mailing list

Reply via email to