Rockbox Development > New Ports

SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

<< < (170/386) > >>

bertrik:
After closer inspection of the OF, it seems the high part of the i2c divider is set with only 2 bits, meaning the total divider cannot be higher than 0x3FF. This should still be big enough to divide any clock down to safe i2c speeds (< 400 kHz).

The OF uses interrupts to handle i2c traffic instead of busy-waiting. This seemed very complicated to me to implement in the intial phase of the port, maybe we should reconsider that. On the other hand an i2c transfer takes only 30 bits or so (75 us at 400 kHz), so maybe it's not worth a thread switch.

Instead of polling the i2c status/busy-bit we could could perhaps poll the i2c interrupt bits. These have not been documented yet though.

daytona955:
Is it likely that the divisor is of the form 1/(n+1)? Since 1/0 is unlikely to have meaning...
So maybe the code should subtract 1 from prescaler before applying it?
At the division ratios needed, an error of +1 on the divisor is not going to have a big impact though.

funman:
Oops sorry for the mistake, I corrected the problem, and also set the clock divider to 10 bits.

bertrik do you think the interrupt bits would be set before the status bits?

Since the as3525 is old now, perhaps AMS would be kind enough to give us the docs for the i2c module.. (they seem to ignore us concerning the AS3531 datasheet needed for Clipv2/Fuzev2 however)

daytona955 : it seems that the divisor is of the form 1/(n+5) ... bertrik can you confirm that ?

stray:

--- Quote from: funman on May 12, 2009, 04:35:25 AM ---
For users with 8GB and more models : don't use test builds because they could totally brick your Sansa.

We don't switch banks in SD transfers when we are crossing a bank boundary, so when crossing the 4GB border, we could accidentally write to the first blocks of internal storage, which hold the Original Firmware.

I noticed this problem when reading ata-sd-pp.c which has a comment line 951. (And by the way, it could be a source of the filesystem corruption the people using Sansa e200/c200 are seeing).

An efficient fix should be relatively easy to do and also applied to ata-sd-pp.c, but in the meantime be careful!

--- End quote ---
Does this bug only affect the internal memory?
So is using a 2GB Fuze with an 8GB microSDHC safe?

/edit: That was fast. Thx :D
 (didn't want to create another useless post)

Hillshum:
Yes and yes.

Navigation

[0] Message Index

[#] Next page

[*] Previous page