Re: [xpcc-dev] Error with I2C eeprom
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
Re: [xpcc-dev] Error with I2C eeprom
Hi, > Could you try writing and reading in chunks of 2 bytes? I just want to > make sure that it's not a problem with only this length. I've updated the gist with writes and reads of 2 bytes, which works fine for me. 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): If a Page Write command attempts to write across a physical page boundary, the result is that the data wraps around to the beginning of the current page (overwriting data previously stored there), instead of being written to the next page as might be expected. Maybe that could explain why you would get 0xFF as the second byte? Cheers, Niklas ___ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Re: [xpcc-dev] Error with I2C eeprom
Hi, > Which specific I2C EEPROM chip do you use? I'm using a 24FC128, specifically chosen because the driver mentioned this family. > You can debug the SoftwareI2C driver by adapting these lines: > https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture/platform/driver/i2c/generic/i2c_master_impl.hpp#L17 > This will give you a reasonable debug output over serial. Sadly, I don't have a serial output connected to a PC, but I mostly got used to it by now. I use the LCD for basic debugging, will see what I can figure out using that. > If that fails, I recommend looking at the physical bus with a logic analyzer. I'm not sure I can get my hands on one, but if the problem persists I'll try. Antal ___ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
