Whow, that's a lot of information about the HW on the PCB and helps me to get some idea how to help
whrnzn :thumbsup:
whrnzn asked me whether I'm able to help him on his issue and that's why I read this thread. I'm a SW engineer familiar with Unix/Linux and have very limited HW background.
As far as I understand the DDR RAM is used by JamMan to persist all the loops in some filesystem and we just have to dump the 512MB DDR RAM somehow on the SD/SDHC memory card. The optional external SD/SDHC card then can be removed from JamMan and then some intelligent data recovery SW can be used on the filesystem.
Given the fact this is an ARM based SOC I assume there is a Linux running in the box or any other similar OS. If it's possible to get access via a console as root a dd command or equivalent can be used to dump the data from DDR RAM to SD/SDHC card. So we have to find some way to get access to an OS console.
I don't think this can be done via the SAM-BA which allows to modify any contents in the NAND flash and to patch and inspect any memory location. I have no idea how it's possible to get access to the DDR and SD/SDHC via SAM-BA. May be I'm wrong - but right now I have no idea how to get this done.
Other ways to access the box may be to use the USART or ethernet port (telnet ?) if they are accessible and served by the running OS. I have no idea how to test whether this will work and how to connect.
There exists a Windows Application which allows to access the internal memory via USB and on section 10.5.3 they write
Code:
10.5.3 USB Device Port
10.5.3.1 Supported External Crystal / External Clocks
The only frequency supported by SAM-BA Monitor to allow USB communication is a 12 MHz crystal or external
clock.
10.5.3.2 USB class
The device uses the USB communication device class (CDC) drivers to take advantage of the installed PC RS-232
software to talk over the USB. The CDC class is implemented in all releases of Windows ® , beginning with
Windows 98SE ® . The CDC document, available at www.usb.org, describes how to implement devices such as
ISDN modems and virtual COM ports.
The Vendor ID is Atmel’s vendor ID 0x03EB. The product ID is 0x6124. These references are used by the host
operating system to mount the correct driver. On Windows systems, the INF files contain the correspondence
between vendor ID and product ID.
There is a CDC driver available for Linux (see
https://www.ccsinfo.com/faq.php?page=linux_cdc for example). Not sure whether this driver can be used to get access to the DDR. They most probably use a proprietary protocol to access and control JamMan and in order to use this interface the protocol has to be reverse engineered.
I just wrote down my thoughts on the issue to give you an idea which alternatives I see. Please correct me if I'm wrong.
Do you think the SAM-BA can be used to get some kind of console? What about the UART? eth would be great but I frankly doubt the drive this from the os because the SamMan uses the USB serial connection for external communication. It also would be very helpful to know which OS is running in the box.