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

[sko]

If I connect my e250v2 to the computer the clock is set to Sep 23 2017 00:00 after disconnecting. If I set the right date/time it is correct until I connect it to the computer again. Is this the normal behavior until now?

[saratoga]

Does the progress that's been made so far with the Fuze also apply to the newer v2 Fuzes, or just the original (now v1) Fuzes?

Not much is known about the V2 hardware.  If its based on the AS353X, then some of the V1 hardware is probably present, and also the mkamsboot code will likely work.  However, until someone starts working on a port, I don't think we'll know for sure.

[epithetless]

Not much is known about the V2 hardware.  If its based on the AS353X, then some of the V1 hardware is probably present, and also the mkamsboot code will likely work.  However, until someone starts working on a port, I don't think we'll know for sure.

Thanks, saratoga. I suspected as much, but it's good to get confirmation on that front.

[Hillshum]

If I connect my e250v2 to the computer the clock is set to Sep 23 2017 00:00 after disconnecting. If I set the right date/time it is correct until I connect it to the computer again. Is this the normal behavior until now?

The OF and Rockbox fight for control of the RTC. The OF's "default" time is Sep 23....
I've been getting that too.

[bertrik]

The RTC in the sansas is basically just a second counter. Earlier sansas keep the time in seconds since January 1st, 1980.

My theory is as follows:
in the e200v2 series the OF keeps the time in seconds since January 1st, 1970 (unix time) and has a check for invalid second values. One such check could be that the time is not before the build date of the firmware itself, which could be September 23rd, 2007. If the RTC is set to a date in 2009 in rockbox (using 1980 as second 0), the OF will interpret this as a date 10 years earlier, in 1999 (using 1970 as second 0). The OF concludes this is an invalid date because it is before the OF build date and sets the RTC to the OF build date, which is September 23, 2007. Back in Rockbox, this value of the RTC counter is interpreted as 10 years later which is 23 September 2017.

To test this theory, we should find out if the build date of the firmware is indeed around sept 23, 2007. It would be nice to know if earlier original firmwares reset the date to a different (earlier) date. Also try to find out if dates after sept 23, 2017 are not reset back to sept 23, 2017.

[sko]

My theory is as follows:
in the e200v2 series the OF keeps the time in seconds since January 1st, 1970 (unix time) and has a check for invalid second values. One such check could be that the time is not before the build date of the firmware itself, which could be September 23rd, 2007. If the RTC is set to a date in 2009 in rockbox (using 1980 as second 0), the OF will interpret this as a date 10 years earlier, in 1999 (using 1970 as second 0). The OF concludes this is an invalid date because it is before the OF build date and sets the RTC to the OF build date, which is September 23, 2007. Back in Rockbox, this value of the RTC counter is interpreted as 10 years later which is 23 September 2017.

Hmm... would it be possible that rockbox does an similar check?

Also try to find out if dates after sept 23, 2017 are not reset back to sept 23, 2017.

I'll check this when I'm back at home (forgot my player -.-).

EDIT: I checked it: I've set date and time correct in RB and connected it to the PC. After disconnecting the OF showed Sep 24 2007 and RB showed Sep 23 2017. Then I set Sep 24 2017 in RB and OF showed Sep 25 2007, I tried one minute too (OF doesn't show seconds, but one second would also be enough I think), same result: no reset. So dates after Sep 23 2017 are not reset back.

[bertrik]

sko, thanks for confirming.
I hope to have a patch (to rtc-as3514.c) by tonight to test/fix this problem. I'm curious to which sansas this issue applies (maybe all AMS sansas?).
The only AMS player I have is a Clip and this one doesn't show date/time in the OF, but early in the Clip port I did notice some time resetting behaviour too.

I created a patch that should fix this problem, I can't test it myself though (I don't have a player with this particular problem): http://www.rockbox.org/tracker/task/9985

[sko]

It works, now RB and OF are showing the same date/time (I set it in RB), good work bertrik!

[funman]

Hello pals!

I started (well, continued) researching about how to access the data on the internal storage past 1GB (on 4GB and more models).

Hopefully I should get a device one of these days, and then I'll be able to experiment some code.

Here are the findings so far:

According to daniel, data reading fails at the (rockbox) sector 0x1dae0 ; which is in fact the hardware sector 0x1e9e00 (0x1dae0 + 61440).

Now just for fun, let's multiply this number by 4:
0x1e9e00 * 4 = 0x787a00 , which is the number of blocks per bank in the e200v1/c200v1 driver... Funny no ?

I found evidence that the OF issues a CMD6 to the storage, which is the command to enable bank switching, so we can't deny that Sansa AMS use bank switching in a similar way than Sansa v1!



Now we need to find how to actually switch banks.
The c200v1/e200v1 driver uses a proprietary command (35) and then writes the bank number into the FIFO buffer.

If the same method is used in Sansa AMS, we need to find the specific command, nothing arised from reverse engineering yet, but it's a tedious task and light might appear any time.


I grepped the OF (various models and versions) for 0x1e9e00 and got no result, but I see 3 occurences of 0x787a00 in 3 different functions.

Note that there is NO occurence in Clipv2 firmware (where storage might be implemented differently) and in m200v2 firmware (where capacity might not exceed 2GB?).


Unfortunately the use of this number 0x787a00 in the 3 functions doesn't tell me anything meaningful ..

Keep on rocking !

[sko]

I enabled battery charging on the sansa clip today. The ams sansas use the same charge controller as the v1 sansas, so it wasn't actually that hard to add it. I didn't enable charging for other ams sansas yet, because each player probably needs its own settings (max. charge current and voltage), but it should be relatively easy to add once we have sufficient information.

What is needed for other ams sansa targets is the following:
* max charge current, this can be determined by measuring the current through the USB cable while it is charging in the OF (and the battery is still less than half full).
* max charge voltage, this can be determined by looking at the battery voltage in the battery debug menu, just after the OF has fully charged the battery.
* battery capacity, this can probably be determined by looking at the battery itself (there's probably already pictures of it in the wiki), from sandisk specifications or from the battery manufacturer.

I looked at my e250v2:
1. varying, I had values between 350 and 400 mAh, OF showed nearly empty (red battery icon)
2. 4.149 V
3. 3.7 V, 730 mAh (see picture)

[Hillshum]

One other thing on the >2gb storage, I have been rolling with the wheel light off quite a bit lately on my e260v2. But It often flashes on once for a sec. When copying files it flickers the whole time. It seems to be tied to reading the NAND or the uSD.

[gabe565]

My 8gb Fuze does the same thing. When the wheel light is on, I'm fine, but once I turn it off, it'll flash on file access.

[kugel.]

I experience it too...sometimes, the other sometimes it works. I haven't worked out a reliable solution yet (and I do think we have worse problems).

[gabe565]

Yeah not being able to read past the first gigabyte needs to be figured out first

[FlynDice]

Do we even have nand on the ams sansa's?  I know there is a nand interface on the chip but it seems sandisk opted to go with an embedded sd card instead(they are sandisks after all...).  My point to that is though that the sd interface uses gpio-d and the button light seems to be turned on with gpio-d[7].  Yes I know the diagram in the datasheet does not show an actual assignment for pin 7 but it would seem that anecdotal evidence suggests that the sd interface is using it for something.  Am I misunderstanding something?