Patch loads on one board, not on the other

#1

ok here is the issue:

a patch that involves loading of a file to sdcard and later to sdram works only on one of my two axolotis.

i load a file on startup of the patch to the sd-card via an object.

the "working" axoloti just does it, no problem.
the non working axoloti attempts to upload the file to sdcard, then reboots and freezes the patcher completely.

if i kill the patcher and reopen it, i can see in the filemanager that the file was written to sd-card succesfully. so maybe the sdram is the problem? can it "break" somehow? can i reset the board in some low level way?

i used the same sd-card on both axolotis to try this.

#2

ok a quick update to make this more testable:

all on the "non working with tables/sdram/sdcard" board

when i open the factory demos sampling sample drum player and take it live without any samples it uploads ok and runs. of course no sounds, and the console complains that the files are not found. so far so good. now if i go unlive (hit ctrl-e again) sometimes the axoloti reboots and the patcher freezes completely, not everytime but sometimes. i suspect there is something faulty with the board and i just did not see it until today, because i never used tables or accesed sdram that way. are there any tests i can do to check if the sdram is ok?

#3

@lokki

It could be a faulty SD-card, or an Sd-card that just doesnt work well with Axoloti. I had some similar odd behaviour from trying different SD-cards. I got a Nashua SD-card which is really slow, works rarely. Then I went and got 2 different Sony Sd-cards. One 90 mgb bandwith and one of 96 mgb bandwith. The one on 90 mgb works very well, but the one with 96mgb bandwith has similar problems like the one you describe; often it cannot find files on Sd-card. Often I can take out the Sd-card and put int back in the machine. It helps a lot of times but not every time. Often I also told by Axoloti that that there is no Sd-card present, like you mention.

This is the exact Sd-czrd that works well for me, 90mgb:
ny-sr16uy3-ultra-micro-sd-kaart-16-gb/9200000014394322/

This is the exact version that works rarely, 96mgb, this one I could only find a Chinese link for.
http://www.huihui.cn/detail_c5a1fece4718b956.html

I dunno if an Sd-card can be "too fast" for Axoloti? Anyway did you use the same Sd-card for both Axolotis? If not, then try using same Sd-card on both of them, to check if there is any difference?

Hope you find the issue :wink:

#4

well, i used the same sd-card on both boards, so i can rule that out, i think...

#5

Ok, sorry, that was my 5 cents.

#6

Could you try to rule out sdram errors? Create a patch with just a delay/write sdram object set to a large size, or maybe connect an oscillator to its input, and the output to audio/out?
Sdram is functionally tested on every board before shipping, and the normal flashing procedure (you've gone through this the first time you connected...) also relies on functioning sdram. Rescue flashing does not use sdram though.

During board startup, the firmware in the processor flash memory calculates a checksum of itself, when you press connect this is compared with the firmware image in the software distribution, and if it does not match it presents the "firmware CRC mismatch" dialog. If you don't get the "firmware CRC mismatch" dialog it's very unlikely that the firmware went corrupt. It's only a CRC32, it is not cryptographically secure, but would detect a corrupt firmware with a very high probability.
After firmware there is still a possibility that a startup patch (either in flash memory or a start.bin file on sdcard) loads but leaves the firmware in a corrupt state somehow. Holding switch S2 during power up will skip loading any startup patch.

To check sdcard: In the main (console) window of Axoloti software it shows if a sdcard is detected ("SDCard mounted") or not ("no SDCard") right of the clear button. This is updated as soon as you eject/insert an sdcard. If it shows "SDCard mounted", it successfully accessed the sdcard. You can also check the presence of files in the File Manager window after clicking "refresh" in that window. Does that work?

#7

i did this:

and the patch goes live, but i get instant output from the delayline (when i change the oscillator frequency it immediately changes on the output of the delay/read. is that expected behaviour? sorry, i never worked with delays so far on the axoloti.

but the sound i get from the delay/read is all garbled, sounds like a heavily aliased squarewave glibberish...not a sine!

i don't see this message, but i see the message running/start.bin when i insert the sdcard and the patch runs, so i assume it is working. i tried deleting the start.bin and uploading another one as startup patch, no difference.
file manager works, if i hit refresh i see all the files, i can delete some, no problem. so it does not seem to be an sdcard problem.

so it "feels" like sdram is somehow broken...

#8

i also tried to flash the firmware, and it seems to work, this is what i get:

Start uploading firmware
firmware file path: /opt/Axoloti/app/firmware/build/axoloti.bin
firmware file size: 588,360
firmware crc: 0x50A29AA2
block uploaded @ 0xC0000000 length 16
block uploaded @ 0xC0000010 length 32768
block uploaded @ 0xC0008010 length 32768
block uploaded @ 0xC0010010 length 32768
block uploaded @ 0xC0018010 length 32768
block uploaded @ 0xC0020010 length 32768
block uploaded @ 0xC0028010 length 32768
block uploaded @ 0xC0030010 length 32768
block uploaded @ 0xC0038010 length 32768
block uploaded @ 0xC0040010 length 32768
block uploaded @ 0xC0048010 length 32768
block uploaded @ 0xC0050010 length 32768
block uploaded @ 0xC0058010 length 32768
block uploaded @ 0xC0060010 length 32768
block uploaded @ 0xC0068010 length 32768
block uploaded @ 0xC0070010 length 32768
block uploaded @ 0xC0078010 length 32768
block uploaded @ 0xC0080010 length 32768
block uploaded @ 0xC0088010 length 31304
Done uploading firmware
Start uploading patch
bin path: /opt/Axoloti/app/firmware/flasher/flasher_build/flasher.bin
block uploaded @ 0x20011000 length 15220
Done uploading patch
Start flashing...
Firmware flashing in progress, do not unplug the board until the leds stop blinking! You can connect again after the leds stop blinking.
Disconnect request
flashing... (ready when the green LED is steady on)

but i found that the patch in question goes live when the sdcard is not inserted, and completely freezes the patcher when the sdcard is inserted and i try to upload. so that would point to an sdcard issue. hmm... strange, since the same sdcard works with the same patch on my other axoloti.

#9

also, loading the patch to sdcard as startup file works as well. it is just when i upload it from the patcher and the sdcard is inserted, the patcher freezes...

#10

if your not familar with the delay line, use one of the help files (for delay) and/or things like the reverb, simply then switch out the delays (or tables) used for the delay sdram.

also you mentioned originally the issue was with a patch that reads/writes from sdcard to sdram,
I suggest you post this patch... so we can see if the same error can be reproduced.

another simple test you could do is to write a script which fills a table/sdram with a value (2^32-1 is a good value) and then reads the values back... (its just a for loop so very simple) , this is what basic ram tests do. you can also play with 'random' values, repeat read/writes...

(personally, Id be more suspicious of the patch/sdcard->sdram that a physical faults, but... good to test all possibilities)

#11

That strongly points towards broken sdram... :cry:

#12

ok, but why can i update the firmware then?

#13

i don't know if i may post the patch here, since it is not mine but @toneburst's. it's his lpc stuff that i am beta testing. maybe i should send you the patch via p.m. rather then posting it here?

#14

@johannes would you mind if @lokki PMed you the file(s)?

It's something I've been working on, but don't want to release into the wild just yet.

a|x

#15

@johannes could I call the crc32 function you mentioned from my own custom object's C code?

a|x

#16

The firmware flashing sequence first copies the firmware image and checksum to sdram, then launches a "magic patch" that reboots axoloti, now running exclusively from sram (not relying on code in flash memory, so flash can be erased/written). At this point the USB connection with the computer is also suspended. Then the magic patch verifies if the firmware matches the checksum. If it matches, the flash memory is erased and the firmware image from sdram is copied to flash, and finally reboots to into normal operation. If it does not match, the red led blinks 10 times, and reboots, leaving the flash memory unaffected.
So if sdram is broken, flashing firmware aborts leaving the flash memory untouched. I have not found a way to keep the USB connection to the PC alive through a reboot of the microcontroller, so the only feedback from the flashing process is through the LED blinking pattern (or via a TTL serial cable).

Of course not

Yes, here is the function prototype:
uint32_t CalcCRC32(uint8_t *buffer, uint32_t size);

#17

Cool. What's the unit of 'size'? Number of 8-bit bytes?

a|x

#18

ok, but i did "update" the firmware and it did work! so that means sdram is not broken? ("update" because i went from 1.0.11 to 1.0.11)

#19

Yes

Well, if it fails, it 'd abort before touching the firmware in flash, and the only feedback from a failing firmware update would be the led blinking sequence.

#20

ok, what does it do if it does not fail? no blinking at all? i will try again later just want to be sure what to look out for :slight_smile: