17:34 <BorgCuba> Hi ppl, how can I teach openocd to erase/write/read flash for my device?

17:34 <BorgCuba> I know the procedure and registers from the datasheet

17:35 <Hawk777> If it’s a chip type that is supported, you would need to just write a config file for the board. If it’s not, you would need to write C code. If it’s very similar to a device that is already supported, you might be able to add it to an existing flash driver; otherwise, you would need to write a fresh Flash driver. Assuming it’s something like an ordinary on-board microcontroller Flash, look in src/flash/nor for examples.

17:37 <PaulFertser> BorgCuba: what's the target core?

17:37 <BorgCuba> The MCU is an HK32F030M cortex-M

17:38 <BorgCuba> somebody else already left some notes on the EN internet: http://nerdralph.blogspot.com/2020/12/trying-to-test-ten-cent-tiny-arm-m0-mcu.html

17:38 <PaulFertser> BorgCuba: is it probably a clone of an stm32?

17:38 <BorgCuba> and has this pyocd script for erasing: https://github.com/nerdralph/HK32F030M/blob/master/hk32erase.pyocd

17:39 <BorgCuba> PaulFertser, very similar but not really compatible I think

17:39 <PaulFertser> BorgCuba: yeah, cool, so drivers for devices like that are in src/flash/nor , do you have any specific questions about it?

17:40 <BorgCuba> PaulFertser, so I have to write C code and build openocd from source? Initially I thought maybe I can just define a .cfg.

17:41 <BorgCuba> Where can I get the source?

17:41 <PaulFertser> BorgCuba: yes, flash drivers in OpenOCD are in C.

17:41 <PaulFertser> BorgCuba: if there's any issue with the official website please report.

17:42 <BorgCuba> I am cloning from the sf.net repo

17:42 <PaulFertser> BorgCuba: good. Is OpenOCD able to talk to the core already? The blog post suggests there's some problem with it.

17:42 <BorgCuba> PaulFertser, yes a little bit

17:42 <PaulFertser> BorgCuba: so what's the trick?

17:43 <BorgCuba> what is the paste bin you use here?

17:43 <PaulFertser> Ah, part2 I should read.

17:43 <PaulFertser> BorgCuba: I personally prefer paste.debian.net or you can cat to nc termbin.com 9999 or probably any other you prefer.

17:45 <BorgCuba> PaulFertser, this is my config and the console output: http://paste.debian.net/1219158/

17:45 <BorgCuba> I can read with mdw and so on but it is not showing any flash banks

17:46 <PaulFertser> BorgCuba: yeah, all looks perfect.

17:47 <Hawk777> Sounds like it’s a Cortex-M but with an unsupported Flash bank, so you’d just have to write a Flash driver for it?

17:47 <PaulFertser> Right

17:49 <BorgCuba> Hawk777, I think you are right. I will have a look at ./src/flash/nor/stm32f1x.c and the datasheet

17:49 <PaulFertser> It might be even compatible to that, yes, if you add the device id and appropriate page sizes.

17:49 <BorgCuba> the register addresses look good so far

17:50 <PaulFertser> BorgCuba: is that chip still available, no shortage?

18:08 <BorgCuba> PaulFertser, available but the price went up significantly

18:09 <PaulFertser> BorgCuba: how much is it now?

18:10 <BorgCuba> I think I bought 30pcs for around 30ct/pc and now its 1.15$

18:10 <PaulFertser> BorgCuba: I think I understand most of the flash driver code so feel free to ask if anything is unclear.

18:12 <BorgCuba> Okay, thanks

18:19 <BorgCuba> PaulFertser, I tried using the stm32f1x config but it complains about the ID value: http://paste.debian.net/1219162/

18:20 <PaulFertser> BorgCuba: where's device id register at according to the vendor doc?

18:21 <BorgCuba> should be the same address: 0x40015800

18:21 <BorgCuba> Ahh, F0

18:22 <PaulFertser> BorgCuba: it's M0 too so 0x40015800 should be used in your case. You can run openocd with -d2 and you'll see what addresses really get accessed when.

18:29 <karlp> is it actually m0 and not m0+?

18:30 <karlp> ah no, that particular stm32 line is from unkonwn devid.

18:32 <BorgCuba> PaulFertser, mdw 0x40015800 gives 0

18:32 <karlp> you're options for permanent are to figure out a way of identifying it, but I can't se anything obvious in that chinese datasheet

18:33 <karlp> or, as a hack, just change the default case to fill in the params you want for your part, instead of rejecting as unknown...

18:33 <PaulFertser> BorgCuba: probably the datasheet isn't too accurate then.

18:34 <karlp> there's also a line on determining flash size, which may not be implemented on that target either.

18:34 <karlp> the stm32f1 impl doesn't really have any hooks for "just pretend it's an f1 with these params..." the way pyocd does.

18:34 <BorgCuba> PaulFertser, section 5.23.1 says that the address of DBGMCU_IDCODE is 0x40015800 and the value should read 0x20000440

18:35 <karlp> which document have you guys got?

18:35 <PaulFertser> BorgCuba: looks like they really tried to mimic stm32f05x then :)

18:35 <karlp> you said it's not reading 0x440 though anyway?

18:37 <karlp> the datasheet on nerdralph doesn't have any section 5 beyond "TBD"

18:38 <BorgCuba> let me see if I can find it

18:39 <BorgCuba> Here it is: https://v1.cecdn.yun300.cn/100001_1901185243/HK32F030%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8CV1.3.pdf

18:40 <karlp> and you say that's reading zero though? at 0x40015800?

18:41 <BorgCuba> yes, but maybe mdw does not work for that address?

18:41 <BorgCuba> how would you read the idcode?

18:41 <BorgCuba> Btw, could you open that URL?

18:41 <karlp> yeah, that doc looks way better.

18:41 <PaulFertser> BorgCuba: mdw it is

18:42 <karlp> I was just trying to see if it needs anything insyscfg turned on to access ram or anything weird.

18:42 <karlp> but nothing obvious.

18:42 <karlp> it seems to try _really_ hard to mimic the f050, with the right part id and all, unlike the APM32 someone was trying here the other day.

18:43 <karlp> even has the flash size register documented.

18:44 <karlp> run it again with -d3 and see all the addresses it access, and what really returns, but it definitelys appears to be not following the datasheet....

18:44 <karlp> (are you sure it's that hk32 and not another type of clone?)

18:45 <bencoh> so now they clone chips, not just boards? funny

18:45 <bencoh> (complex~ish chips I mean)

18:46 <PaulFertser> bencoh: since long!

18:47 <PaulFertser> bencoh: https://zeptobars.com/en/read/FTDI-FT232RL-real-vs-fake-supereal already quite complex

19:03 <BorgCuba> karlp, this is with -d3: http://paste.debian.net/1219164/

19:05 <BorgCuba> karlp, the part number on the chip suggests its a HK32F030MF4P6 and I bought it from lcsc.com

19:14 <BorgCuba> can mdb display data like hexdump does with -C?

19:14 <PaulFertser> BorgCuba: no. Use dump_image and then hexdump

19:15 <BorgCuba> PaulFertser, good idea

19:16 <BorgCuba> seems it actually is preprogrammed with some code

19:16 <PaulFertser> BorgCuba: you can try debugging it :) "reset halt" and then "step" "step" "step" :)

19:17 <PaulFertser> Probably used for production testing

19:18 <BorgCuba> PaulFertser, here are 64k data starting at 0800.0000: https://termbin.com/lp0v

19:20 <BorgCuba> whats the objdump target -m arm ... thumb ??

19:20 <bencoh> trying to disass it?

19:20 <BorgCuba> yes

19:21 <PaulFertser> BorgCuba: the beginning looks strange, it should have stack pointer address and then reset handler address with thumb (lowest) bit set.

19:21 <bencoh> you could even try do "decompile" it if you're really into it (retdec for instance)

19:21 <BorgCuba> just for fun, to see if it makes any sense

19:22 <BorgCuba> but I think I have an old IDA version somewhere

19:27 <BorgCuba> makes kind of sense: https://termbin.com/e01t

19:30 <BorgCuba> btw, it is -D -b binary -m arm -Mforce-thumb for objdump

19:30 <PaulFertser> BorgCuba: probably the first page was overwritten later by some other tests

19:31 <BorgCuba> PaulFertser, could be

19:31 <BorgCuba> still I did not manage to read the idcode

19:32 <PaulFertser> BorgCuba: ignore it, try to treat it as if it's an stm32f0 device with 128 bytes page size

20:21 <BorgCuba> PaulFertser, do stm32 targets initialize clocks at startup?

20:22 <BorgCuba> there are RCC bits for the DBGMCU but enabling the DBMCU and resetting it does not yield an IDCODE != 0

20:24 <PaulFertser> BorgCuba: not by default, but debug clock is generic and should be enabled by OpenOCD.

20:25 <BorgCuba> yeah, and the flash is also readable

20:25 <BorgCuba> so some clocks should be running

20:26 <BorgCuba> PaulFertser, without idcode and flash-size this device would not fit in with stm32-flash drivers I fear or what do you think?

20:28 <PaulFertser> BorgCuba: wouldn't fit upstream but you should first see if it works at all as a quick hack.

20:33 <BorgCuba> PaulFertser, so you suggest I should remove the idcode check and hardcode flash size, build openocd and then try to flash the hk32 with the stm32 driver?

20:41 <BorgCuba> general question: will risc-v bury arm?

21:04 <BorgCuba> Btw, does openocd read erased flash as all 0 or 1?

21:05 <PaulFertser> BorgCuba: different MCUs have different erase flash bits.

21:05 <PaulFertser> BorgCuba: OpenOCD reads what's really there.

21:05 <BorgCuba> In this case it seems to be all 0s

21:06 <PaulFertser> That's possible.

21:16 <PaulFertser> BorgCuba: arm, pic, avr, stm8 etc didn't bury 8051 and mips.

21:21 <BorgCuba> good point

21:43 <BorgCuba> I just entered the erase sequence manually. But after reading it back its mostly 0 but some bits are set, i.e. occasionally you can see a 1 2 4 8.

21:58 <BorgCuba> Maybe its due to my very cheap setup: 2 pull up resistors(clk,io), 3 caps, µusb, ch551g (as cmsis-dap usb adapter) and hk32f030

22:26 <bencoh> are you certain the erase really "worked" though?

22:29 <BorgCuba> bencoh, how can I be sure?

22:29 <BorgCuba> What I could verify is that the memory looks more 0ish now

22:29 <bencoh> that's a good start I guess

22:30 <BorgCuba> because I dumped 0x8000000 before and after the erase

22:48 <BorgCuba> good night boys