Hi,
>> 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 xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev