-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flashed a CH582M badge with 11x55 instead of 11x44 LED's and now its bricked - no OEM-backup available #59
Comments
Can you please post a picture of the back of this board and while it loads the boot logo? I think this badge has different assigned pins. Also, is this board 11x44 LEDs? The current state of the firmware does not support any board different than 11x44. There is no prebuild firmware with DEBUG enabled. You can manually build one, but it will not log anything other than USB's debug log. |
Now i realize that it is a 11x55 badge. I did not know such existed. I knew about the ones with 11x44 and the ones with 12x48. So i have count 11 rows, checked about the chipset and flashed the firmware. There is a 240fps video running the 0.1 firmware with its boot animation. The video file is too big to upload to github. So i had to upload it somewhere else: I probably have now to develop the things for the different resolution. I would be happy if i could just use up 11x44 of the 11x55 rows but i do not know if this would somehow work and be more easy for the development part. Probably i would have to also modify the badge configuration software to make it working with 11x55 if its not possible to just ignore the more LED's and use just 11x44 of the badge. |
I bought an 11x55 badge when preparing for GSoC and realized it's the wrong version. Here is my 11x55 badge: It looks like some last few columns were hacked up to use Charlieplexing with fewer pins than usual. But not sure if my badge is the same as yours.
To modify the firmware for your badge, first trace the LEDs according to Charlieplexing then change the assigned pin here: badgemagic-firmware/src/leddrv.c Lines 71 to 99 in 321677c
You might want to change the button pin as well: badgemagic-firmware/src/button.c Lines 13 to 14 in 321677c
badgemagic-firmware/src/button.h Lines 12 to 17 in 321677c
The battery measurement pin: badgemagic-firmware/src/main.c Line 338 in 321677c
The charging pin: badgemagic-firmware/src/main.c Lines 121 to 122 in 321677c
badgemagic-firmware/src/main.c Line 359 in 321677c
And yes, it is un-unified. I was thinking of converting these pin configs to an HAL module where we can config the pins for each version of the badge easily. |
I got asked to flash a WCH CH582M badge a person had. Person have it some longer time ago probably from a opensource-conference. So we expected to be a fossasia-badge. It look similar, have CH582M, so the firmware got flashed.
Now the badge is bricked. Because the closed source firmware are read-only a OEM-firmware-backup does not exist.
Fossasia Version 0.1 .bin was flashed. Reflashed 3 times but no working state.
How does the current state with the 0.1 look like and how does it differ from the fossasia badges i have:
Bootloader worked like known. I disconnected battery, pressed and held the button next to the micro-USB connector and could write to the badge with wchisp.
The situation when i get some life out of it is after flash with disconnected battery. It then show some completely broken looking animation that should probably be the fossasia bootlogo.
After showing the unreadable animation its dead. Buttons does not work. They seem to be mapped different on that board or something else is wrong. It does not matter what or how often i press the buttons.
When i disconnect and reconnect the battery, the badge do not get back to life like it does on the other ones.
Just powering over usb can bring the badge to life with the wrong output.
I left the badge with battery disconnected because of its now fully unknown state. It should not kill its battery because of the state it is in now.
I expect i have to try debugging over UART, right? Is there a prebuild firmware file with UART (DEUBG=1) enabled?
The text was updated successfully, but these errors were encountered: