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

[daytona955]

I think CLK_DIV probably does the right thing (although with out any description...), in that it gives a divisor that means the actual generated frequency does not exceed the target.

But when used with hardware that avoids divide-by-zero by treating n as 1/(n+1), the output from CLK_DIV needs adjusting. See for example

Code: [Select]

CGU_PERI |= ((CLK_DIV(AS3525_PLLA_FREQ, AS3525_PCLK_FREQ) - 1) << 2)
                | 1; /* clk_in = PLLA */
in system-as3525.c.

A quick grep shows it is used without adjustment in setting the DBOP, I2C2 and SD ident clocks. But I've only checked that the DBOP case is actually wrong (so far).


Edit:
Maybe the incorrect setting of CGU_DBOP is why funman gets this issue in FS10048:
Also I find it weird that UI becomes much slower when we divide pclk by 2 : the DBOP frequency should not change that much since it's lower than pclk anyway... do you have an idea why?

Now I have a build where DBOP clock == PCLK, and a fix to the programming of CGU_DBOP (adjust divisor by -1).

I have done a few builds with different PCLK values. I tested UI responsiveness by an ad-hoc test: how well the rotation of the spacerocks ship tracks the scrollwheel. 

With the fix to CGU_DBOP I now get decreasingly poor responsiveness with PCLK frequencies of less than 41.333...Mhz. 

Before fixing CGU_DBOP, changing PCLK (& therefore DBOP clk) had all sorts of strange effects, including white screen, scrambled screen, non responsive UI.

[funman]

Thanks for hunting that bug!

Indeed I think this is the source of the LCD problems we saw.

The OF uses dynamic clocking for pclk, fclk, and all peripherals, and every setting is checked at each change, but I think we can avoid that with preprocessor checks like:

Code: [Select]

#define DBOP_DIV (CLK_DIV(....))
#if DBOP_DIV > 8
#    error "dbop clkdiv too high"
#endif
CGU_DBOP |= (DBOP_DIV - 1) << x
Also the pclk should be set to its exact value (62M) not the maximal value, to calculate correct clock dividers..

EDIT : another bug I just reminded of

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!

[wpyh]

EDIT : another bug I just reminded of

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!

Oops... I just upgraded my Fuze 8GB with the latest SVN. It's still working fine even though I have crossed the 4GB boundary though.

I thought we already switch banks when accessing the internal storage? Otherwise, how can it boot from >4GB?

I hope the fix can get in soon.

[saratoga]

I think you're confusing the bank switching problem (which is fixed) with a newly identified problem: writing across the bank boundaries (which is not).  Rockbox can actually boot without write support at all (see the D2 port for instance).

[FlynDice]

funman:  Isn't i2c input from PCLK?

line 56 clock-target.h
#if (CLK_DIV(AS3525_PLLA_FREQ, AS3525_I2C_FREQ)) >= (1<<16) /* 2*8 bits */

[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]

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!

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

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

[Hillshum]

Yes and yes.

[jago]

Hello!

Nice work until now. Thanks  .
I own a sansa e260 (4Gb) and I have big problems with revisions higher than r20922.
With r20923 started the trouble. My sansa freezes every few minutes or I get error messages like this: *panic* flush_fat_sector() - could not write sector xxxx (error -101)
There must be something problematical with this commit, at least for my sansa.
I am back on r20922 now and all is fine.

[funman]

Can you update to last svn again, and change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000 ; and see if this fixes your problem ?

I suppose that the problem is the change from 90MHz to 66MHz , perhaps we need to adjust it a bit.

We used 248/((248/90)+1) = 82.666MHz and now 248/((248/66)+1) = 62MHz IDE clock

When using PLLA at 384MHz, the OF uses 384/((384/66)+1) = 64MHz clock (perhaps not always since there is more than one PLLA setting in the OF)

[FlynDice]

Need some help if anyone has had this happen.  I can't access my internal memory through usb and the OF anymore.  I can access the microsd card just fine though and I can copy from it to the internal memory ok using rockbox.  Tried a different cable no luck. Different computer, no luck Copied a new copy of a rockbox bootloader to the internal card and it went through the firmware upgrade process just fine but same results with usb.  Anyone got any ideas for me?

EDIT: Nevermind, I took a chance and reformatted with the OF and it restored my connectivity with the internal disk, Whew

I'm attaching a patch that puts some clock debug info on the debug view hardware page.  I believe the sd numbers are out of whack but the rest work I think.  The assumption is that PLLA is at 248MHz and I've tried to pull the actual divider values out to see what the clock values are ending up as for the various peripherals. Your mileage may vary of course...

[stray]

Can you update to last svn again, and change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000 ; and see if this fixes your problem ?

This fixed my Fuze. Before i had to try several times to get the database to build, got some *panic* errors etc.

[jago]

change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000

I have just tried.
Seems to solve the problem.