Rio

hi and welcome, Do you want to drive an update? Is there already firmware on it? Then it is possible to upload the firmware (newer bootloader or newer mbsidv2) via midi. What response do you get when you use mios studio 2, connect and set "midi in" and "midi out" for your device and you press the "query" button for example for "device ID:" 0? But please don't load a hex file for it yet ... first you need to look at which ID and version the PIC is responding. Greetings!

Please be careful with such suggestions of implementation and if it is useful please only suggest this as an explicit option. Other data can also be transmitted to MIDI IN (routing, etc.) than just what is to be recorded (even while recording ...).

Hi, "Midi solutions" tools (like Merger, Thru aso.) are only powered via midi. I wonder if that would also be possible with a simple pic core module (stuffed with a PIC18F452, where no hungre lcd etc. are connected). I just want to process some midi data from IN to OUT. greetings, rio

That could be investigated...just unclear. You mean, the port confusion should not have been a problem.

yes and no. Regardless, the h2testw test program shows me a lot of errors, the card is useless and it's not a SDHC - it's a SD, and nobody sells such SDs anymore. But, I just want to know if something is wrong on my hardware setup, or if someone else notices these things (long formatting time, hanging on startup, aso.) and if something could be fixed (on hardware: possibly through additional stabilization or possibly software adjustments). Strangely, I have tested 2x Sandisk Extreme SDHC 4GB, 1x Medion SDHC 4GB and 1x Medion SDHC 32GB. All cards show the same behavior.

Update: I have now tested an SD Extreme III 1GB - FAT. No problem. sdcard_format command is finished in 1sec. The Card is never undetected - SEQ always boots. The problem only occurs with SDHC (FAT/FAT32), tested > 4GB. Ok and now a few screenshots of my tests (with CH2 (blue) - RC1/CS# trigger): 1a. switched on 1b. switched on (another one) 2. Screenshot after booting (while the logo is displayed - before the card is read) 3a. Tried detect/read SD - and failed 4. After a failure, it always stays down for a few seconds. That remains until the next attempt. Then happens the same again and again (Screen 2, 3, 4), except I plug the card out / in. Then it will be interrupted and the card can then be recognized often. 3b. Another try detect/read SD - and failed 3c. Another one - failed And now a few screenshots, if the SD card is successfully detected after the boot: 5a. Successfully detected 5b. Successfully detected 5c. Successfully detected It's hard for me to make a difference to the failed detection. But maybe you recognize something from it. The lower blue line is the spectrum of CH2. I have CH1 (yellow) taken directly from the LF33 and it always looks stable (about 3.2 V). Best regards, rio

Do you mean to change trigger to CH2 in openhantek? And do you mean there must load on RC1 through the SD connection e.g. during boot? this will be hard to pinch the probes without shortening the circuit...

Update: 1. I screwed out the core board and looked at all solder joints. Looks clean. 2. sdcard_format command works, but it takes a long time for the SDHC card!! Contrary to my assumption that sdcard_format crashes the seq - that's not true. It works with success but it takes for the 4GB up to 15 minutes and it just gives me until then no status. So I assumed it crashed. I did not know that there is no status message of the process. Is that the same with you? The long time for formatting for SDHC 4GB is also reported here: http://midibox.org/forums/topic/17763-sdcard-problem/#comment-156398 Regardless, I also specified the bootloader to use a single USB port...

ok now the screen with full connected MIDI devices...That looks ok - no drop down. But the SD itself is no longer connected, as I have clamped the DCO's probes to the pins of J16. But, unfortunately I noticed that my x0xb0x was inadvertently connected from OUT2 of SEQ to MIDI THRU instead MIDI IN and it ran and I did not notice it the last couple of times. It has supplied both devices with lower voltage once one is turned off :/. Are the ports not protected? - but I did the measurement and the screenshot and CH1 still looks good (even if it was wrong connected). I've plugged it right again and once did the tests with the SD card. But, the behavior remains - sometimes it does not start with SD with full connection of all devices. if I remove 5 devices from it, then it always boots with sd (once found .. then everything works.). Besides: what I also noticed that the sdcard_format command does not work for the faster cards (SDHC), even if no devices are connected and even if no Quad IIC boards, no MIDI IN / OUT, no J8, no J9, no LCDs are connected anymore. LPC17 freezes immediately after sending command. That should not happened, but I've never noticed it, because I have never used that command before (since I built the box). Does something already show what's going on with it? What should I check next?

The screenshot below shows (as recommended by Antichambre) Vd (CH1 yellow) and RC1 (CH2 blue) of J16. This is on the fly, without any devices at the ports. I could not recognize long spikes when switching on (its to fast). That looks ok? Although Vd is slightly below 3.3V (3.2). Next time I hang up all devices

hey that's a lot of information. Thank you. I'll turn on the DCO. As background: I use 12x MIDI OUT and 3x MIDI IN ... fed by LPC Coreboard +2x Quad IIC boards. I know - it's a lot but I only live once.

I want to update openhantek (software for certain DCOs) before doing some tests. It seems that the last official version supports the dds120 ... Update: I got the last openhantek 6022 variant running with dds120. It is not possible to record directly inside, but I can configure following params: I could export a CSV or save it as PDF. Additionally I can zoom and measure (as tools).

with "Ground connected" do you mean that I should connect both "Probe ground clip" to the ground of the SEQ, right?

I will test later. j16E is from the LPC17 core board, right?

I can do that. do I have to pay attention to DCO connections? I have a dds120 here: https://sigrok.org/wiki/SainSmart_DDS120 the probes can be switched 1:1, 1:10. The software is a modified openhantek variant ... however, what is completely unclear, why is the failure rate dependent on the amount of devices connected and powered on the midiports?

it goes through this loop: https://github.com/midibox/mios32/blob/3cb2f368e39a686451ce2759966530251f455681/mios32/common/mios32_sdcard.c#L181 and ends up here: https://github.com/midibox/mios32/blob/3cb2f368e39a686451ce2759966530251f455681/mios32/common/mios32_sdcard.c#L190 and MIOS32_SDCARD_PowerOn is repeated thereafter (after a while)

a delay - based on? The startup is already delayed enough by the logo display (about 3 sec)

I need an accurate timing, especially when reading data. where did you get the SPI speed information from?

I would like to find out why there is a problem with the cards or if there is a common problem with the massive port connections of external devices in conjunction with the SD cards and if there is a possibility to solve it via a hardware or software solution (for stable boot/detection)

The Sandisk Extreme 4GB is a SDHC. The other slow card has a writing speed of 2 MB / s - so i would like use the extreme.

A slow card (1Gb) always seems to be running. This has FAT as file system and I can override it via sdcard_format in terminal. For the Sandisk 4GB Extreme: the SEQ will usually hang there (as well as when booting). I have a second Extreme Card. It shows the same behavior... So the card ist NOT defect. After successful formatting with SdCardFormatter for that card, nothing has changed.

I could try it, but I do not think it changes anything. it seems to me that the mass of the devices that hang up is decisive. Can this possibly be fixed by sourcecode? (possibly for the loop when initializing, because then it runs constantly, as soon as the card recognized...) @gerald.wertI have a USB dco at hand, I'm not sure how I can meaningfully measure what.

I have replaced the cable with a thicker and kept the cable as short as possible. but unfortunately it did not improve. Does somebody still have an idea?

I had thought so synonymous and turned off one by one (for each boot process), but in the end, no statement can be made, which device is the cause, but it depends only on the amount of devices which are connected and turned on.

Hey, thanks for the first hints. I have now tested the following: if I provide no power to all my devices, which are connected from SEQ through several ports (INs, OUTs,IICs) , then the SEQ boots always fine with detected SD. It starts to hang more often when more devices are turned on while booting. And yes hawkeye - it's true - it only affects the bootup. Once detected, the SEQ is working fine with the SD. I'll take your advice with the wiring...we'll see, or someone else has a different guess.