LICH patch loading errors

#1

Hello!

I just finished building the LICH and am looking forward to integrating it into my modular setup…which is still in it’s infancy…so having LICH is going to really help!

Anyhow, I completed the build did a little testing and then plugged it in. The module powers up and runs the included patches and I have been browsing around trying some others. However, some patches do not seem to load or might in one instance and then not in another.

When loading the Melsutter it seemed to work, but when I select it on the front panel it looks like it is loading and then appears to give an error and then revert to patch 1.

I am unsure if this is related to a hardware issue (a short somewhere or faulty connection) or if there is something goin on in software/firmware land that might cause this.

Has anyone else experienced this issue? If so, were you able to solve it? Any suggestions about what the root-cause might be? Is there any additional information that may be helpful?

Thanks!

#2

Hi @mentok,

For starters, which firmware version are you running?

There’s always some chance of corruption when device get flashed. So on software side, there are a few things to try:

  • try different firmware. I would suggest trying v22.2.0 and v21.2.2 . The first one is latest stable release and it uses external flash chip for storage (8Mb). The other one is the last to use internal flash (~0.5Mb). As they use different location for storing patches, you would be able to at least rule out a problem with patch storage
  • erase patch storage, just in case if that makes any difference

As it’s a DIY build, checking everything for soldering errors is a good idea too.

1 Like
#3

It could also be the patch, some of them probably don’t work right on the Lich.
Melsputter was developed for the Lich so definitely should work, though it might be a bit of a weird patch.

Did you go through all the functions of your Lich to test that it works: buttons, CVs et c?

#4

Thanks for the reply!

I will try the different firmwares and see. I re-loaded the latest firmware but have not tried an older one, so I will do that and report back

I think I erased the patch storage once…but will try to do it intentionally this time :wink:

The soldering issue is what I am worried about…I really don’t feel like lifting the pots to check…but am worried there is a long lead somewhere there :frowning:

#5

Thanks for the reply!

I was kinda hoping that might be the case to some degree…but I tried loading only patches that had [LICH] on them (assuming they are built for LICH) and Melsputter worked at first…then didn’t. I have gone through all the patches, but I know at least one other worked and then didn’t as well. I need to build some patience and check all the patches I tried…just need time…lol!

EDIT:

I realize I did not answer this Q…I did not do a run through of all functions but will do that

#7

So tried out FW 21.1 and tried loading a few patches in and once I got up to the fourth patch the one I loaded gave an error:

  • Error: Error 0x60 Invalid STORE command

I have a suspicion that it is not the patches, but in case it helps here is what I loaded:

1 - [Lich] Melsputter
2 - [Lich] Knoscillator
3 - [Lich] Dual sample and hold

I tried to load the following into bank 4: [Lich] LADR

That patch does not show as loading. Also, the seven (eight) segment display shows ‘E’

I think I am going to open it up and check for any soldering issues…

#8

I doubt that it’s something that is special to a particular patch. Does it always happen if you try storing the same patch again?

The error happens when you’re trying to store a patch that wasn’t successfully uploaded to memory. So this might be something hardware related (bad soldering, funky USB cable). Sometimes you may get corrupt data from browser too, I think this might happen if multiple tabs with RebelTech patcher are open.

#9

Thats what I was worried about. I changed out the cable (a couple times), I checked the solder connections, especially where the pots sit above the pins and trimmed any long leads. Then powered up, and attempted to load [Lich] Polysequencer in spot 10, the front panel display showed a ‘U’ then ‘E’ with the dot illuminated.

I then did “Erase Storage” and tried to reload a couple patches and the web interface displays: Error 0x80 Invalid flash resource

Also, to be sure I closed out all other applications that may have been interfering with MIDI interface.

I was hoping not to resort to sending over to Befaco cause $$, but at this stage it seems that may be my only option :frowning:

I definitely appreciate all the responses and help!

EDIT: (meant to answer this too)

Yes, The two I have noticed it occurs the most are [Lich] Polysequencer and [Lich] Melsputter

#10

Could this possibly be related to a corrupt memory on the OWL board itself?

#11

Yes indeed, we have a problem! The good, and the bad, news is that it’s not just you, @mentok.

I just tried storing those two patches on a Lich with the latest firmware, and I think I see the same issue: device reset when the patch is selected. Another one that fails is [Lich] Stoke Patterns. Very weird that it works when loading to RAM, but not when storing and recalling from flash.

I will try to troubleshoot this and hopefully have a solution very soon.

#12

Really?!? While bad news in one context, I am at least feeling sane and not alone… I was looking for bad solder connections…tore the thing apart to find any stray shorts etc…even sent in an email asking if there was any other possible explanation! Thank you :grinning_face_with_smiling_eyes:

I had also tried that patch and noticed the error and thus stopped trying to load it.

#13

After endless hours digging and debugging, I eventually uncovered the source of the problem. As is often the case with the trickiest bugs, there was not just one but a nexus of issues, causing intermittent and hard-to-trace faults.

At the core of it though was something really mundane. It turns out that in the HAL libraries from ST, SPI data transfers can only be up to 64k in size because the data length is limited to 16 bits.

Writing to flash was working fine, because it is done in pages of 256 bytes each. And the data verification method I had implemented, which reads a patch or resource and sends it back out over MIDI, that was also working perfectly because the data was chunked into SysEx messages. CRC checksum verification on the stored data also passed, again because it was done in chunks at a time.
But reading a whole patch into memory and then executing it, well, you can imagine: random little bit-sized fireworks going off in all directions.

As a result of tracking down this problem the code is now much more robust. The checksum is verified every time a patch is loaded into memory. And we have a firmware mechanism for downloading patches and resources, which opens up some possibilities for the future.

This also fixes the problem that has been reported elsewhere with large samples not playing properly in the QuadSampler patch.

I’m just wrapping up a firmware release candidate now, 22.4.rc1; it will be announced in a separate post.

OpenWare pre-release v22.4.rc1
#14

Oh my, I haven’t considered the DMA transfer size in SPI storage, but actually it’s possible to switch to 32bit transfers to double that limit. I’ve used it with ILI9341 display driver, but not sure if it’s that useful here considering that even 128kb is less than max patch size. Can provide some sample code if there’s interested to cut number of transactions in half (just a few writes to SPI register and writing to HAL handler are required).