If I change reset halt to halt in the Makefile, it seems to work. Hm. Experimenting…
It looks like it’s the problem with reset that I’ve mentioned before. You can try commenting out “reset_config srst_only” in Hardware/openocd.cfg. There’s another line in the bottom of that file that may be used instead. Or it may work if you comment out both lines and use default settings used by openocd.
Is there anything useful you can do with the debugger when the white board is just sitting alone on a tabletop?
Well, it’s not terribly interesting without the attached board, it would probably fail or hang somewhere during device initialization for unconnected peripherals. But you can at least use it to step-through bootloader initialization in order to have some idea how debugging works, what you can see in debugger (variable state, peripherals and CPU registers, disassembled code, memory contents, etc).
It looks like it’s the problem with reset that I’ve mentioned before. You can try commenting out “reset_config srst_only” in Hardware/openocd.cfg.
Great, thanks so much! Commenting this line out worked (as long as I did NOT uncomment the final line). I was able to run make upload. It gave me “Verified OK”. (make flash also worked.)
My questions at this point are:
- Is there a difference between
make flashandmake upload? I don’t findmake flashin the appropriate Makefile. - What would uploading Magus.elf look like? Would
$OPENOCD -c "program Magus/Build/Magus.elf verify reset exit"probably just work?
Running OPENOCD “program” just worked! Maybe I will try reassembling now. Antisvin, if you want to provide any help or references on running a debugger, I will link them in my guide and probably I will have cause to try them out myself later.
“make upload” is the correct command to use. The other one was either Martin’s brain fart or it could be renamed.
If you upload FW like that, it will overwrite bootloader. It’s possible to specify address for upload to upload, so that FW would land where it’s supposed to be stored. But the easiest way is just to restore bootloader if necessary and load firmware over MIDI.
Made a separate thread for this. Sorry if there would be any mistakes in config - it’s edited copy of what I’m using on other device currently.
@antisvin, thanks so much!
Is there a trick to inserting the IO board? If I just stick it in where it seemed to have been before, the parts are all sticking out through their holes at a slight angle. I don’t seem to be able to push it down enough for the parts to go through straight.
I don’t remember doing anything special, it should align when you push the USB device port through the case and tighten the nuts on jacks.
Hm, so I encountered something sort of bad. Maybe this is a @mars question.
I installed first MidiBoot.elf, then Magus.elf (before I saw antisvin’s warnings… I had hoped that the ELF files would know to install the two at different offsets) and then reassembled the unit. I decided to initially power it by USB because that is more convenient. I plugged it into the USB hub on my Windows machine.
When I plugged it in, Windows displayed a popup saying “power surge on USB port. the device tried to request more power than the USB plug can supply”. After this, neither the hub nor the PC USB port the hub had been plugged into worked until I restarted Windows. After restarting Windows the hub and the PC USB port both worked fine. Plugging the Magus into the hub used to work.
After this, I got out the Magus AC adapter and plugged that in. The screen did not turn on.
What would be the best way to proceed? Should I go back and reinstall MidiBoot.elf instead of Magus.elf?
Midiboot has a setting for limiting current, not sure how exactly it works. @mars - maybe it should be set by default in devices.h instead?
#define USBD_MAX_POWER 100 // 100mA for iPad compatibility
Midiboot has a setting for limiting current, not sure how exactly it works
Interesting-- would this be something that changed? Again, I’ve successfully used USB before the reflash.
I think it’s OK to draw a reasonable amount of power, after all, I’m hoping to simultaneously plug it in to USB-HOST and plug in USB DEVICES at the same time (if this has any chance of working…)
First off make sure that the digital board is correctly fitted and no pins are bent out of shape.
Sounds like something is not correctly aligned. There’s a photo somewhere - ah yes:
it looks like this?
Pretty sure that the question was about IO panel, not digital board. Anyway, I’ve taken it out and I think I understand the described issue. The panel comes in under a slight angle first, then you need to push it gently to set all connectors in place. This makes a sort of soft click sound.
Oh my gosh, success!
It does appear that I seated the white board into the wrong pins last time. I’m glad I didn’t seem to have fried anything. The IO board “clicked” as antisvin mentioned and I booted.
The screen said “Failed to start program task” at startup; when I looked, all my presets were deleted. Is this surprising? Was there something I could have done while the programmer was attached to back up and then restore my presets? (Maybe I absentmindedly attempted an erase operation at some point while I was trying to figure out lock/unlock?)
My Magus is now running and I am powering from USB, BUT, I am no longer able to talk to it in USB HOST mode. If I go to the “patches” page on rebeltech.org, or the firmware upload page, Chrome does not appear to see it as a WebMIDI device. The firmware upload page does nothing when I click “Reset to boot loader”, and the patches page says “Failed to Connect to Owl” when I say “connect to device”.
Could the new USB/IRQ code have caused this?
You should probably confirm that downgrading firmware restores USB functionality.
I’ll try building v20.7 with IWDG. There’s no way to force into the bootloader from the interface, right? The IWDG bootloader will kick me into bootloader if I crash, but nothing’s crashing right now, I just don’t have USBH.
Not at the moment, MIDI has to be used. But something like that can be added, actually adding feature to Magus UI is not very hard. And there’s a procedure for returning to bootloader (which is used by MIDI handler, obviously).
You may try running a patch with infinite loop, this would probably block everything and IWDG will fire. Well that was a fairly dumb suggestion, I agree.
…ohhhkay. I’ve got some time to work on the Magus again. This is… messy.
To recap, my situation as of last post was:
- I built and installed an IWDG MidiBoot and an IWDG Magus, from git:efaaa7661bde
- I installed first the MidiBoot, then the Magus, via the programmer
- The goal was to see if the IRQ changes made USB Client work without drops
- After rebooting, all my patches were missing, and USB Host did not work. I was not able to test USB Client because I don’t know how to upload patches without USB Host connectivity.
- antisvin suggested I re-install a pre-IRQ patch to see if that restores USB Host connectivity (so we can see if something is wrong with my device, or if the problem is with git:efaaa7661bde)
My situation now is:
- I built and installed an IWDG Magus, from tag v20.7. To do this I added
#define USE_IWDGto Magus/Inc/hardware.h , generated the files from Magus.ioc and then uploaded via the programmer (on top of my existing git:efaaa7661bde MidiBoot) - When I boot, the screen comes up and shows my old patches. After about four seconds, every bootup, the screen goes blank. I interpret this as the IWDG firing and kicking me into MidiBoot.
- If I open up OpenWareLaboratory once the screen has gone blank, I see
Firmware version: OWL Magus Boot v21.0
Device Message: Watchdog reset
Device Message: Watchdog reset
Device Message: Watchdog reset
Device Message: Watchdog reset
Device Message: Watchdog reset
From this, my conclusions:
- For some reason the v20.7 IWDG and the MidiBoot IWDG are not talking to each other correctly
- However, the fact firmware.html was able to talk to MidiBoot means USB Host is still working on my device
- Therefore, the USB host failure in git:efaaa7661bde is because something is wrong with git:efaaa7661bde
@mars, what do you suggest I do?
is it surprising v20.7 is triggering the IWDG despite the Magus/Inc/hardware.h define?
Can git:efaaa7661bde be fixed?
@mcc it sounds like you’re calling USB host/device opposite way from what how they are exposed on device. This is a bit confusing. As in, USB device is used to connect to PC for installing patches, host is used for connecting other USB devices (and this is what you’re planning to test)
Regarding watchdog stuff, the way it’s written is that MCU registers are set directly when this flag is enabled in preprocessor. So there’s pretty much no code to break - as long as it’s compiled, it would work. So far it looks that you’re running FW built without watchdog enabled.
Also, pretty sure that I’ve used Magus as USB device on latest code recently.