And here’s the other side of my board…
Thank you for providing the pictures. Unfortunately I didn’t spot anything obviously wrong. Just in case, check this picture out:
The components enclosed within the orange outline are critical for USB communication, as well as the 3 pins marked with light green dots. Please double check whether the solder joints on theses components are indeed fine (they do look fine from the picture, but maybe looking at them at an angle could reveal something). Also, double check if the microcontroller pins didn’t get bent when inserting, to remove it from the socket, use some slim long-nose pliers or long tweezers to slide underneath and lift the whole body at once. Removing the optocoupler first is a good idea. 
Another thing to try is to keep the B button held down for a few seconds during and after plugging in the USB cable, or powering on the device with cable already inserted.
By the way, you mentioned other Arduino boards - do you have a tool that could flash the memory of ATmega328P? We haven’t seen this occur before, but maybe the chip itself is flashed incorrectly - if it’s fuse settings were not set correctly, the USB won’t work, but the bootloader logo would still show up. This could be checked and fixed using a programmer or another Arduino board set up for In System Programming (ISP) and avrdude.
Do you have the original Arduino UNO board by any chance? If so, I think you could pop the ATmega328P in it and inspect it.
I’ve triple-checked the component soldering and IC pins for bends and all seems ok.
I’ve also checked for shorts and the continuity of connections (e.g. from IC pins to diodes, resistors, etc) using a multimeter and everything seems fine.
Unfortunately I don’t have an UNO board to test the ATmega328P, only Leonardo boards. But I have just ordered an UNO dev board off eBay; I should receive it next week. Hopefully that helps shed some light on the problem… I’ll report back soon…
1 Like
Hi again. I finally got hold of an UNO dev board off eBay. I’ve swapped the ATmega328P chip on the dev board for the MidiBoy chip and connected to my PC. I’m not getting any USB errors and it seems to be recognised within the Arduino IDE software (e.g. on port 6). How do I go about inspecting the MidiBoy chip to check that it is 100% okay? Or do you think the chip is actually fine and the problem is with one of the other components? (e.g. diodes)
1 Like
The Arduino UNO board gets recognized, because it has an FTDI USB To Serial chip, for programming the ATmega328P controller - the controller itself does not have direct access to USB via the USB port on the board.
Let’s try this - on Arduino IDE, select Midiboy as the board in Tools menu, and Arduino ISP as the Programmer, pick the COM6 port (or how it corresponds on your OS), so the settings look similar to this:
Also, in File->Preferences, make sure these options are enabled:
Then with the Midiboy’s ATmega328P inserted into the Arduino UNO (do any chip swaps only with USB unplugged), do Tools->Burn Bootloader.
Additionally, you may open a sketch in Arduino IDE, like https://patchstorage.com/midimon/, and from its window, do Sketch->Upload (or you may even have to do Sketch->Upload Using Programmer, not sure which is the correct one to use)
Then unplug the USB from the Arduino UNO, and insert the recently programmed chip into the Midiboy, and give it a try. It should hopefully be recognized as a USB device, and run the Midimon sketch. In bootloader mode, it should be programmable straight from the Arduino IDE, just make sure to select USBasp as the programmer. The selected Port is irrelevant for this kind of programmer, as it autodetects the device itself. See https://blokas.io/midiboy/software/5/ for OS specific notes, and the other steps of the guide for additional information on the programming process.
If it does not get recognized, then please retry with just flashing the bootloader, and testing it out.
In case you get any errors in the output log at the bottom, please post the contents here, so we can take a look and figure it out.
Ok, so I’ve changed the settings to those outlined above and selected Tools->Burn Bootloader, but I get the following error message “avrdude: Error: Could not find USBtiny device (0x2341/0x49)”
Ok, looks like I’ve specified the wrong Programmer to use. Please try again using ‘AVRISP mkII’ or ‘Atmel JTAGICE3 (ISP mode)’
Hi again, sorry to dredge up this old topic again, but I’ve been unable to test out your suggestions until now.
I tried using the different programmers listed above, but both resulted in errors. Using ‘AVRISP mkII’ gives the following messages:
Also, I’ve now got 2 Arduino UNO dev boards, so I thought I would try setting one up as an ISP programmer and one as a target. This works fine for uploading the UNO bootloader and sketches. Could I use this method to upload the Midiboy bootloader and sketches? I tried selecting Midiboy as the board and then ‘tools->burn bootloader’ but this didn’t work, but I suspect I’m doing something wrong?
No worries at all! 
Yes, it should work. What output did you get when doing this?
Could you copy and paste the whole output here? The ‘Copy error messages’ button should put everything in clipboard.
Looks like I found the issue, and fixed it in the Blokas Boards - the port number was unintentionally getting overridden when doing Burn Bootloader.
I’ve just published 1.0.6 version of Blokas Boards with this fixed, follow the steps here to get the update:
1 Like
It’s working!!! Thanks so much for your help mate. Just uploaded the Midimon sketch and it’s working great 
Thought I might be going crazy there at one point! 
Sorry, I may have spoken too soon… I’m now back to my original problem from my first post where I get the error message “USB Device Not Recognised” when connecting via USB to my PC.
I’m assuming we can now rule out the ATmega328P chip as being the source of this issue?
Would you recommend I start replacing the components you circled in orange (in the 4th post) one by one to find the culprit? Starting with the diodes?
At least I now have a method to upload sketches to the Midiboy! (although it is quite cumbersome)
When the Midimon sketch is running, is the device recognized as a USB MIDI device by the system?
No, I’ve used MIDI-OX to check and I see nothing. It appears in Device Manager as an “Unknown USB device”:
Also, holding down the “B” button whilst powering on does not bring up the Blokas logo and put it into programming mode - it does nothing - all I see is the Midimon input | output screen the entire time.
You should see the Blokas logo after doing Burn Bootloader. Uploading sketches via the bootloader & USB should keep it there.
This does show though that the issue lies somewhere else than the chip itself. I have double checked your photo of components again and I still can’t spot anything wrong there. Of course inspecting photos is not the same as the real board itself.
Could you post another photo of circled area at an angle, both sides of the board?
Here are the close-up photos:
Also, not sure if this is relevant, but when I upload the Midiboy bootloader using the UNO ISP I get some avrdude warnings in the log that seem to be related to fuses. For example:
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: reading input file “0xFF”
avrdude: writing lock (1 bytes):
*Writing | ***failed; *
################################################## | 100% 0.07s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xFF:
avrdude: load data lock data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lock data:
*C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v1 -PCOM6 -b19200 -Uflash:w:C:\Users\Stephen\AppData\Local\Arduino15\packages\Blokas\hardware\avr\1.0.6/bootloaders/Midiboy-Bootloader/Midiboy-Bootloader.hex:i -Ulock:w:0xFF:m *
Reading | ################################################## | 100% 0.01s
avrdude: verifying …
avrdude: WARNING: invalid value for unused bits in fuse “lock”, should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0x3f instead of 0xff (double check with your datasheet first).
avrdude: 1 bytes of lock verified
avrdude: reading input file “0xFD”
However avrdude still finishes the bootloader upload process with the message “avrdude done. Thank you.” and no errors are reported.
I’ve been playing around with a sketch located here (Gammon Forum : Electronics : Microprocessors : Sketch to detect Atmega chip types) that returns info on the bootloader and fuses etc. It seems that when I upload the Midimon sketch the Midiboy bootloader gets wiped. But when I re-flash the Midiboy bootloader, the Midimon sketch gets wiped. I can’t seem to get both the bootloader and the sketch on the chip at the same time using the UNO ISP! (note that when the Midiboy bootloader has been flashed, I get the Blokas logo on the Midiboy screen but still get the “Unknown USB device” when directly connecting the Midiboy via USB to Windows)
Perhaps this has something to do with it?
Here is the output from the Gammon sketch after flashing the Midiboy bootloader:
Atmega chip detector.
Written by Nick Gammon.
Version 1.20
Compiled on Mar 10 2021 at 10:31:16 with Arduino IDE 10813.
Attempting to enter ICSP programming mode …
Entered programming mode OK.
Signature = 0x1E 0x95 0x0F
Processor = ATmega328P
Flash memory size = 32768 bytes.
LFuse = 0xCE
HFuse = 0xD8
EFuse = 0xFD
Lock byte = 0xFF
Clock calibration = 0xAB
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 4096 bytes starting at 7000
Bootloader:
7000: 0xB3 0xC0 0x00 0x00 0xF0 0xC0 0x00 0x00 0xCA 0xC0 0x00 0x00 0xC8 0xC0 0x00 0x00
7010: 0xC6 0xC0 0x00 0x00 0xC4 0xC0 0x00 0x00 0xC2 0xC0 0x00 0x00 0xC0 0xC0 0x00 0x00
7020: 0xBE 0xC0 0x00 0x00 0xBC 0xC0 0x00 0x00 0xBA 0xC0 0x00 0x00 0xB8 0xC0 0x00 0x00
7030: 0xB6 0xC0 0x00 0x00 0xB4 0xC0 0x00 0x00 0xB2 0xC0 0x00 0x00 0xB0 0xC0 0x00 0x00
7040: 0xAE 0xC0 0x00 0x00 0xAC 0xC0 0x00 0x00 0xAA 0xC0 0x00 0x00 0xA8 0xC0 0x00 0x00
7050: 0xA6 0xC0 0x00 0x00 0xA4 0xC0 0x00 0x00 0xA2 0xC0 0x00 0x00 0xA0 0xC0 0x00 0x00
7060: 0x9E 0xC0 0x00 0x00 0x9C 0xC0 0x00 0x00 0x7E 0x3F 0xF9 0xF7 0x6A 0x39 0xF9 0xF7
7070: 0x56 0x35 0xF9 0xF7 0x40 0x38 0xF9 0xF7 0xEC 0x2D 0xFD 0x2D 0xB7 0xB6 0xB0 0xFC
7080: 0xFD 0xCF 0x27 0xBF 0xE8 0x95 0xB7 0xB6 0xB0 0xFC 0xFD 0xCF 0x21 0xE1 0xB7 0xB6
7090: 0xB6 0xFC 0xF4 0xCF 0x08 0x95 0x04 0x03 0x09 0x04 0x1C 0x03 0x77 0x00 0x77 0x00
70A0: 0x77 0x00 0x2E 0x00 0x66 0x00 0x69 0x00 0x73 0x00 0x63 0x00 0x68 0x00 0x6C 0x00
70B0: 0x2E 0x00 0x64 0x00 0x65 0x00 0x0E 0x03 0x55 0x00 0x53 0x00 0x42 0x00 0x61 0x00
70C0: 0x73 0x00 0x70 0x00 0x12 0x01 0x10 0x01 0xFF 0x00 0x00 0x08 0xC0 0x16 0xDC 0x05
70D0: 0x02 0x01 0x01 0x02 0x00 0x01 0x09 0x02 0x12 0x00 0x01 0x01 0x00 0x80 0x32 0x09
70E0: 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1F 0x07 0x03 0x01 0x01 0x00 0x00 0x00
70F0: 0x00 0x00 0x01 0x01 0x03 0x07 0x1F 0xFF 0xFF 0x1F 0x07 0x03 0x01 0x01 0x00 0x00
7A70: 0x0F 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
…etc…
7FF0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
MD5 sum of bootloader = 0x88 0x8A 0xBA 0xB4 0xAD 0xC5 0x22 0xF3 0x1F 0xEA 0x81 0x26 0xFE 0x71 0x7C 0xA2
Bootloader MD5 sum not known.
First 256 bytes of program memory:
00: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
…etc…
F0: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Programming mode off.