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

[freqmod]

If buffering is the problem then FS#9332, should fix it. (you'll have to change a strncpy to strlcpy  to make it compile).

I have tried it for a few minutes with an usage that results in the buffering problems w/o the patch and currently it works quite well. I got a codec error when i changed a track, but the next track started as usual.

[kugel.]

STOP POSTING BUG REPORTS IN THIS THREAD. THIS IS FOR DEVELOPEMENT.

Post them here instead: http://forums.rockbox.org/index.php?topic=22137

[pixelma]

What does the radio debug screen say ? (system -> debug -> radio), FM radio worked fine on my c200v2 when i tried it

Well actually the radio is now working, dont know why it wasnt working yesterday but somehow is working now.
Playing music still crashes. So why on the SansaAMS page it shows that Playback is working?

This reminds me of the early days of the c200 v1 port - the radio wasn't detected sometimes (reboot helped) or the tuner got confused sometimes (starting radio in the OF helped). There were a few related fixes but the former still happens to me, very very seldom though. All I'm saying is that it could either be a general problem - and/or something that already happened in a similar way during the c200 v1 development.

Sansa AMS developers: Feel free to remove this post if you don't think it adds something useful, or move.

[krloz]

Hello! I am new to this forum. I don't have the required level of developing knowledge for RockBox but I do have a Sansa E250v2 and really want to collaborate testing the new port! please tell me how can I test RockBox on mi device

[yapper]

I do have a Sansa E250v2 and really want to collaborate testing the new port! please tell me how can I test RockBox on mi device

See this topic: http://forums.rockbox.org/index.php?topic=22137.0

[Orivej Desh]

Hello there!

I've got Sansa Clip (v1) 2gb with FM radio and having a problem of black screen. When I turn the player on, I hear a quiet click in headphones but display remains black. Unlike matsch's (http://forums.rockbox.org/index.php?topic=14064.msg150808#msg150808), my display is completely black and when I plug in USB, nothing shows up on screen. This proves that something is running, because when I turn the player off, pluggin in USB shows standard connected/charging screen.

I tried to increase dcdc voltage as described here (http://forums.rockbox.org/index.php?topic=14064.msg151005#msg151005) with no success. (I have recompiled both rockbox and bootloader).

Dual boot doesn't work either. Neither repeated tapping on the |<< (or any other) button, nor holding it long has any effect. OF boots only after plugging and unplugging USB.

Tested with svn r22531 and gcc 4.3.3.

[kugel.]

Can some e200v2 owner test the two lastest patches I posted to http://www.rockbox.org/tracker/task/10272 please?

[X-Dan]

Hi everybody!

And Thank you all for the great work you have all done :-)

I have just a question. I want to know if someone has or will implement the line out dock functionnality?

[iudex]

One question:
Does anyone working on buffering problem on Clip?
I can test all your work.

[matsch]

One question:
Does anyone working on buffering problem on Clip?

Please try patch #10605. Should give some playback improvement.
Side effect on changing form mp3 to ogg playing possible.

[cpnfantstk]

Would patch #10605 apply to the M240v4 as well ?

[saratoga]

Yes, however I investigated 10605 tonight and I don't think it will make very much difference.  The first case it addresses shouldn't happen if you only listen to MP3, and the second seems to occur so rarely I was not able to encounter it. 

[matsch]

Yes, however I investigated 10605 tonight and I don't think it will make very much difference.  The first case it addresses shouldn't happen if you only listen to MP3, and the second seems to occur so rarely I was not able to encounter it. 

When I apply the patch to my clip, it makes a difference. In case of skipping a file manually, the codec (50kB) is loaded into the ring buffer. If it is not loaded a crash occurs less often. As to the second patch: How stable it is i cannot tell, but I had some album play with skipping and no crash occured. The albums crashed before the patch.
I like to point out, that the patch is not solution of the playback issue, but an improvement.
Understanding buffering.c is difficult. Especially moving a handle in the ring buffer with move_handle and buffer_handle

[saratoga]

If you didn't see this already you might find it interesting:

http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-09/0049.shtml

[FlynDice]

I'm not really getting any good results while investigating the AMS Sansa SD
situation so I thought that I would just toss out some of my thoughts and observations
for your reading enjoyment.  Consider it fodder for future wisecracks perhaps or
maybe a futile gesture to the AMS Rockbox Gods to open my eyes so I may just
see what must plainly be there....

There are 2 different problems with the sd cards that I'm aware of:

1. We're running them too fast and out of spec at 62 MHz
2. I can read from the uSD but not write to it nor delete from it reliably.
    The Internal card works fine with both operations.
    I can copy a file USD -> INTERNAL  but not INTERNAL -> uSD
    I can read and play files from the uSD just fine.

Besides being removeable, the most obvious difference in the configuration
between the cards is that the uSD is connected to the bus through GPIOD.
I tried commenting out the GPIOD_DIR &= ~(1<<7) we use to keep the buttonlight
off on disk access with no luck.

My goal for awhile now has been simply to get the SD cards running below the
specification limit of 50 MHz.  I have been able to do this only by lowering
PCLK to below 50 MHZ as I cannot get any setup where MCICLK != PCLK to function
over the data pins.  The cards are set at 400 kHz for the ident mode and they
initialize just fine but that communication happens over the cmd pin and not over
the data pins. I believe the significant difference is the fifo involvement
with the data lines but I'm not sure about that.  The fifo should act as
a buffer between the two clock domains when PCLK != MCICLK so that is what
draws my attention here.The linux driver for the pl180 uses the fifo half
full and half empty interrupts for dma control and we don't. I thought
that having the pl180 control the dma transfers handled the fifo and
dma requests but I'm still trying to figure this part out.  I understand
what interrupts are and how they work(barely) but actually implementing them
is a bit beyond me at this point, if that's even the solution here?


Things I have tried with results/observations:

I'm not advocating using all these things it's just what I have tried...

I have been able to run the cards within spec from 30-50 MHz by lowering
PCLK to this range.  That's the only way I can do it.  The clock bypass bit
must be set, the cards will not work without it.

Omitting the SD_SET_BLOCKLEN command for initialization works fine.  We
assume a 512 for transfers and this is in fact the default value so issuing
this command is redundant.

I have been able to switch to high speed timings by using the SD_SWITCH_FUNC
command for both the internal and microSD cards with no problems.

I have been able to initialize the cards while running them at full speed
(62 Mhz) with no problems.  I believe the 400kHz Ident freq is a holdover
from MMC Cards.  We are sure we're dealing with an SD card because that's
all that fits.....  The SD spec does say you should send a 400 Khz clock
during the ident phase but I believe that's just for compatibility with
MMC cards.

I omitted the SD_SET_BUS_WIDTH command and can't notice a difference.  This
is the command to change from 1 bit to 4 bit data bus.  We have been issuing
this to the cards without changing the controller to 4 bit mode.  I cannot
get 4bit mode to work at all with the internal card but with the uSD I
can display folders and album art. I cannot play music though.  I adjusted
the burst size for pcm dma with no luck.

I enabled the synchronization logic for DMA and found no difference.  The
pl081 docs say the logic must be enabled if the peripheral sending the request
and the SDMAC controller are in different clock domains.

I modified the debug viewHW page to reliably display the sd freqs.  Because
we turn off the controllers between disk accesses you need a disk access
to get a reading.  Inserting the uSD will get you a reading.

I'm pretty much stalled out here so maybe someone else can help connect
the dots!