crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
ts_ has quit [Quit: Leaving]
Steffanx has quit [Ping timeout: 268 seconds]
Steffanx has joined #openocd
tarekb has joined #openocd
The_Jag has joined #openocd
Bertl_zZ is now known as Bertl
tarekb has quit [Read error: Connection reset by peer]
DefekC has joined #openocd
<DefekC>
Hi! Has someone ever worked with Geehy APM32F0xx series MCUs in conjunction with OpenOCD?
<DefekC>
This MCU is basically equivalent of STM32F0xx series with Cortex-M0+ core. All register mapping is identical (I haven't checked it all, but compiled 14kB HEX for STM & APM are identical).
<DefekC>
Currently I am working in KEIL using ULINK2 programmer. This is good for development, but not suitable for automated production line (write HEX, set option bytes, lock memory etc).
<DefekC>
It looks like APM does not have flash driver in OpenOCD, and "stm32f1" doesn't do the trick.
<DefekC>
Any suggestions?
<PaulFertser>
DefekC: hi
<PaulFertser>
DefekC: but you say flash controller should be similar to stm32f0, right?
<PaulFertser>
DefekC: so what happens if you use that?
<PaulFertser>
DefekC: hm, I see, it's stm32f1x. So what does stm32f1x say about it?
<PaulFertser>
DefekC: please use some pastebin to show -d3 log.
<PaulFertser>
DefekC: you can also try searching the gerrit for message:apm32 in case someone has already offered a patch.
<DefekC>
I expect flasher to be ... the same?
<DefekC>
Geehy provided me with .cfg file for MCU - it is basically copy-paste form STM with only change being CPUID (APM = 0x0bc11477, STM = 0x0bb11477).
<DefekC>
If I use "stm32f1x" driver, console returns this during programming: Error: Cannot identify target as a stm32x
<DefekC>
If I just connect to MCU without attempting to program anything, it is fine...
<DefekC>
P.S. - I am very new into OpenOCD. My background is mostly KEIL or STM IDE as far as tool-chains go, so... yea.
<DefekC>
PaulFertser, could You please explain Your last two comments?
<PaulFertser>
DefekC: OpenOCD uses https://review.openocd.org so there might be some apm32 patch pending there.
<PaulFertser>
DefekC: isn't the STM IDE using OpenOCD?
<PaulFertser>
DefekC: you can look at -d3 log and then modify src/flash/nor/stm32f1x.c accordingly if there's no existing patch.
<DefekC>
Yes, STM uses OpenOCD, but ... I am new to it.
<DefekC>
The very base problem is that I have to change STM32F051 to APM32F051. So far STM has provided perfect tools for doing all I want without much thinking. This is why everything in tool-chains for me have been pretty seamless.
<DefekC>
I already looked into OpenOCD source and I am considering an attempt in adding some extras, but I *hoped* I was not the first one...
<DefekC>
Ok, I get what You're saying... I'll look up if there is something in progress.
<karlp>
plus some new deviceids, and you need to look at what geehy has wrt to device ids, and make sure they don't conflict with st's ones.
<karlp>
if you have a ref manual you can link ( in english) I could maybe be more concrete...
<karlp>
the datsheet pdf in the sdk download just has a single page linking to a broken url on geehy somewhere.
<karlp>
so I can't go further
<karlp>
you _might_ be able to just copy tghe device id register from the f0 line above, and _might_ be all you need, if they imitated the f051 device id, but that would seem unlikely honestly.
<karlp>
making the periphs compatible is one ting, but pretending outright seems unlikely...
<karlp>
it should be relatively straight forward though, when yo have the right docs
<karlp>
the big switch on deviceid is around line 730 onwards, you should be able to see what's going on there and be able to make a case block for your new part.
<karlp>
there's probably another place that looks at the cortex part number as well, stm32x_get_flash_size() at least.
<karlp>
run in -d3 and see what it says the device id is.
<karlp>
that might work as is.
<DefekC>
Thanks, karlp! I'll try it tomorrow. It is 20:30 for me - I was forcefully sent home! CoVid lockdown... :D
<karlp>
the manual you linked doesn't describe the values of (DBGMCU_IDCODE) so I can't say more without having the hardware.
<karlp>
you may need to follow that #6164 changeset for more ideas on how to differentiate your parts from the standard st parts, but see what device id yours reports first.