TK.

It was too late for the first order, but you will get the chance to buy some of the remaining, unpaid chips at 25-08-2008, 8 p.m. CET (see http://www.midibox.org/forum/index.php/topic,11387.msg97347.html#msg97347) I will start a second order once we reach 250 (or 500) pieces again Best Regards, Thorsten.

ok, fixed The driver is still not available for public, but it won't take so long anymore :) Best Regards, Thorsten.

Thanks - fixed Best Regards, Thorsten.

This seems to be a copy&paste error, in this variant: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsm_c_example2%2Fsm_fast.asm the debounce counters are cleared instead I think, that the second loop can be savely removed - could you please doublecheck this? I could give you write access to the repository, so that your additional comments won't get lost Best Regards, Thorsten.

The workaround for "dash" (which is used as default shell instead of bash) are already in the repository There is a new environment variable which has to be set by Ubuntu users: export MIOS_SHELL=/bin/bash For the case that you haven't downloaded the repository yet, just type: svn co svn://svnmios.midibox.org/mios Best Regards, Thorsten. P.S.: the applications will be re-released once the modifications has been tested well enough on different operating systems.

Great!!! :) I documented this requirement in the README Best Regards, Thorsten.

Im Prinzip sind die Ideen nicht schlecht, doch es mangel wie so oft an verfuegbaren Speicher. Im Bootloader-Bereich sind bspw. nur noch 22 bytes frei, da passen also nur noch 11 Assembler Befehle rein. Das reicht nicht. Deshalb muss man sich damit zufrieden geben, fuer einen Funktionstest eine LED an den MIDI Tx Pin anzuschliessen. Damit werden zwar nicht alle Fehlerfaelle abgedeckt, doch die LED sendet immerhin ein "Sign of Life" IMHO reichen zwei Tests aus, um die Funktion des Cores in wenigen Sekunden festzustellen: TEST_OUT1 und TEST_INOUT1 - wenn die nicht funktionieren, beginnt die Fehlersuche - und hierbei wuerde ein erweiterter Bootloader nicht weiterhelfen. Stattdessen muss man nach wie vor die bereits dokumentierten Testreihe durcharbeiten. Gruss, Thorsten.

Thanks, this was helpful. :) The corrupted part of the file neither contains the original content, nor it contains the intended values. Instead, all the upper sectors contain the same pattern: 00004000: f8ff ffff 0300 ffff 0500 ffff 0700 ffff ................ 00004010: 0900 ffff 0b00 ffff 0d00 ffff 0f00 ffff ................ 00004020: 1100 ffff 1300 ffff 1500 ffff 1700 ffff ................ 00004030: 1900 ffff 1b00 ffff 1d00 ffff 1f00 ffff ................ 00004040: 2100 ffff 2300 ffff 2500 ffff 2700 ffff !...#...%...'... 00004050: 2900 ffff 2b00 ffff 2d00 ffff 2f00 ffff )...+...-.../... 00004060: 3100 ffff 3300 ffff 0000 0000 0000 0000 1...3........... 00004070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ [/code] Looks like a FAT Oh damned! It [b]is[/b] the FAT! ;-) So, here the solution: use SDCARD_FILE_Seek() before copying the SRAM content into sdcard_buffer_p0/sdcard_buffer_p1, because the seek function overwrites this buffer during FAT readouts This explains all observed effects. Best Regards, Thorsten.

Did you also check your core module? Note the "flying wires" (see http://www.ucapps.de/mbhp/mbhp_core_v3.gif) which are required if you don't use a PCB from Smash Best Regards, Thorsten.

This is due to a known bug in PBrennerNG (I already informed Sprut): unix style files without carriage-return control chars won't be read correctly. Workaround: open the file with wordpad, do a dummy-modification (e.g. insert/delete a space), and store it again. Wordpad will store the file in DOS style Best Regards, Thorsten.

Thank you, I fixed this Best Regards, Thorsten.

Hi, thank you! This was probably the oldest bug ever. It seems that not that much MIDI devices are using the song select message... The bugfix is available in the repository: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fmios%2Fmios_isr.inc Best Regards, Thorsten.

MIDIO128 would be better, as ain64_din128_dout128 sends random events when pins at J5 are not grounded. Details: http://www.midibox.org/dokuwiki/din_module Are the buttons working with this application? LEDs connected to J5: there was a bug in the j5_io driver under modules/j5_io - MBSID V1 hasn't been rereleased yet, so that you have to download the new j5_io.inc file from this location Best Regards, Thorsten.

Alright - do you already have a binary file which contains the expected SRAM content? Could you please post it together with the file read from SD-Card? Best Regards, Thorsten.

Yes, we were talking about both methods See detailed description in README.txt Yes You could use an external IIC EEPROM ("BankStick") to store and restore your presets. Up to 128 presets can be stored in a single device. No PC required to replace data. The example shows, how to handle this Best Regards, Thorsten.

What is the type number of the IIC EEPROMs? If they are manufactured by ST, the CS lines (pin 1-3) won't work. AMD EEPROMS: Pin 3 won't work. Only Microchip EEPROMs (24LC512) will allow you to use all chip select lines. So - my assumption is, that you are using ST EEPROMs Best Regards, Thorsten.

This issue totally rankles me - did I already mention, that I love such text adventures? ;) With WinXP you are able to specify the cluster size by using the "format" command in the DOS shell, e.g. [tt]format <device>: /FS:FAT /A:16k[/tt] will lead to a cluster size of 32 sectors (0x20) d: is the <device> ID (e.g. k: for my SD card reader) But there are also dependencies between partition and cluster size, e.g. with a 1 GB partition the minimum cluster size is 16k, otherwise FAT16 (65536) cannot cover all clusters (16k * 512 * 2^16 = 1 GB) You could try this cluster size, but I guess that I won't solve the issue. The traces and variable dump are still consistent. E.g., we can see that the file starts at sector 0x45e 00000000158385 ms | Sysex message: F0 00 00 00 00 00 04 05 0E F7 and that it ends at sector 0x49d 00000000173943 ms | Sysex message: F0 00 00 00 00 00 04 09 0D F7 512 bytes * (0x49d-0x45e+1) = 32768 -> correct Between 0x49d and 0x45e the sector number is continuously incremented -> correct Means: SDCARD_FILE_Seek() always returns the correct sector number in sdcard_file_sector, because this is the value which is dumped by the SysEx string at the end of SDCARD_FILE_Seek() The other variables lead to correct calculations as well (don't want to go too much into detail here...) Between SDCARD_FILE_Seek() and SDCARD_WriteSector() I don't see any modification of the sdcard_file_sector variable in your code -> good By using a different cluster size, you've proven that SDCARD_WriteSector() itself, but also your PROG_SRAM_Read() function is working, otherwise the file would still be corrupted after 2k So, I need some more input. - check the same with a cluster size of 16k (probably this won't lead to new results, data corrupted after 16k?) - check your SDCC version, it should be 2.8.0 (or higher) -> type "sdcc --version" - if this doesn't help, I will send you a routine which dumps the SRAM content + the interesting sectors of your SD card for easier comparison - it should give us the final answer :) Best Regards, Thorsten.

It looks fine - SDCARD_FILE_Seek() goes through the FAT to search for the cluster (smaller strings). The longer strings contain the found sector number in nibble-format - the sector number is increasing, which indicates, that a) the file system isn't fragmented (it doesn't matter anyhow, the algorithm can also work with fragmented partitions), but more important: that the FAT algorithm is working. To doublecheck smaller cluster sizes, I re-partitioned my own SD-Card with gparted, and formatted it with 2k cluster size. I was able to reproduce the bug with the previous sdcard version, and tested the new one - successfully. The sysex_overwrite application modifies .syx files with 64k size correctly. My assumption is, that the filesystem of your card is corrupted due to the experiments with the previous version. Random things can happen if random sectors are written ;) Did you already re-format your sdcard? Best Regards, Thorsten.

There is a second "#if 0" which has to be enabled as well - it tells me the finally found sector (I will check this tomorrow evening) Best Regards, Thorsten.

Now with an alternative format (2 nibble format) and a documentation (-> see README.txt) http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsyx_dump%2F Additional enhancements are not planned from my side. Best Regards, Thorsten.

0x800 means, that the next cluster has to be read in the FAT In order to debug this, I need some more informations: open sdcard_file.inc, search for "#if 0", and replace it by "#if 1". After rebuild and application upload, some SysEx messages should be sent on each file access. Copy&Paste the SysEx strings which are dumped during a write operation Best Regards, Thorsten.

cool! :) Btw.: I never noticed this error, since the low byte of the next variable, which was accidently used as high byte during the operation, is 0x00 with my SDcard, but 0xbe with yours ;) Best Regards, Thorsten.

Ok, I think that I found the issue - expected value was 0x00be, but you got 0xbebe due to a wrong 16bit operation Update is in the repository: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fsdcard%2F (you could also try an update via tortoise, it should work now) Best Regards, Thorsten.

Could you please doublecheck, if this value is correct: _sdcard_file_sector_cl2 0x000a16 BE BE [/code] Best Regards, Thorsten.

My test files are usually bigger than 64k, so that they allocate multiple clusters. With the SRAM read function of MIOS Studio you could dump the sector content which is read (probably starting at 0x100, check the project.map file), and also the sector variables (starting at 0x80, absolute addresses can be found in the .map file as well) The content of following variables would be interesting (please note: check the project.map file for the addresses used by your application!!!) _sdcard_file_mode 0x000080 _sdcard_file_name_ptr 0x000081 _sdcard_file_cluster 0x000084 _sdcard_file_sector 0x000086 _sdcard_file_dir_entry_num 0x00008a _sdcard_file_dir_entry_ptr 0x00008c _sdcard_file_sector0 0x00008f _sdcard_file_sector_fat 0x000091 _sdcard_file_sector_root 0x000093 _sdcard_file_root_sectors 0x000095 _sdcard_file_sector_cl2 0x000096 _sdcard_file_cluster_size 0x000098 _sdcard_file_seek_offset 0x000099 _sdcard_file_seek_cluster 0x00009d The most interesting variable is _sdcard_file_cluster_size, because this one could be different at your side. Also the content of the MBR (sector #0) and the parition boot sector (sector number in _sdcard_file_sector0) could be interesting (if _sdcard_buffer_p0 and ..1 is located at 0x100/0x200, dump 0x100..0x2ff) Best Regards, Thorsten.