Hey everyone, would appreciate some help on this matter:
I’m trying to build a midi bootloader for an stm32f103 so I’ve looked through a lot of the code on the yarns bootloader since it’s f103 based if i’m not mistaken.
I’vre previously managed the simple bootloader where the program to be flashed is in an array in the bootloader program, and that works perfectly, so I wanted to take it to the next step and be able to send the firmware in sysex format through midi.
If you look at my code it’s very similar to the yarns bootloader program currently and I also have an oled screen for a visual representation of what’s going on. what I’ve figured out so far is that the ring buffer (stmlib/utils/ring_buffer.h) function “readble()” is never true and thus skips to jumping to the main program. I cannot understand why this is happening though.
The logic behind it, if i’m not mistaken, is wait for midi input, parse it through the buffer, check if it’s sysex and correct, start copying from the buffer to flash memory and when it’s finished -> jump to main firmware.
Adding the outer while loop for exit_updater helped not jumping to firmware, however, you misunderstood.
I did not mean that the function by design always returns false, of course…
What I meant was that in my application I must have done something incorrectly and the ring buffer doesn’t seem to be available at any point. For example right now it is running constantly in that outer while loop waiting for the function to return true for it to enter the inner while loop and start copying to flash etc.
To be honest, I’m still trying to completely understand the ring_buffer code so I can be able to debug and figure out what I should be doing.
Thanks for the reply.
As a side note, one reason I might be having a hard time with understanding some of your code is because I’m currently using the HAL library (because of cubeMX). Do you think it’s a waste using this library and software?
So you have to check that some bytes are actually put in the ring buffer somewhere else. This can be done either by handling an interrupt raised whenever the UART receives a byte, or by periodically polling (say every 0.125ms) the UART. The former approach is how I do it:
Note that this code is in the interrupt handler for the SysTick timer, and that it is configured to run at 8kHz.
You also need to check that the UART is correctly configured, that the related peripheral clock is running, that the GPIO pin is configured with the right alternate function etc.
Hmm UART is configured properly and does work, I checked earlier with a simple note-on / led on-off. I’ll have a more in depth look at the systick & buffer polling part, maybe i’ve misconfigured something there or maybe something slipped my attention.
I hope it’s something like that which would prove easier to fix rather than scratching my brain trying to debug the rest…
Update: So I managed to get the bootloader working great, however I now have an issue with the .syx files.
I’m using the hex2sysex tool and although some hex files convert great, I have some larger ones that don’t match the corresponding hex files, which is really weird. Is there a problem with larger files?
I could be wrong but it seems that although jumbled up, all the bytes match and are in there, but in the first case it is not…
the only options i use in the python script is setting product id to 66 and page size to 1024
I noticed this because while programming via midi/bootloader and looking through the flash memory, the bytes were not correct so I went to look at the sysex data and there I saw this mismatch.
I could be wrong of course, maybe it’s something normal? I don’t know
It’s because the .hex file reader I wrote ignores the “Extended Linear Address” field of the HEX file, ie, it’s tailored for files under 64k (simply because I have never developed any MIDI upgradable device with more than 64k of code).