crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #openocd
rolf has quit [Remote host closed the connection]
rolf has joined #openocd
diddly has quit [Ping timeout: 256 seconds]
diddly has joined #openocd
MGF_Fabio has quit [Ping timeout: 276 seconds]
Haohmaru has quit [Quit: saionara]
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #openocd
pedro_pt has joined #openocd
nerozero has quit [Ping timeout: 264 seconds]
Hammdist has joined #openocd
<rolf>
Hi all, I did several patches, including updating the flash driver for PSoC6 dual core ARM. As I am looking to add some more functionality (Kitprog 3 driver), I like to know how long it may take for the patch to get accepted (before spending more effort on OpenOCD)
Hawk777 has joined #openocd
<PaulFertser>
rolf: hi!
<PaulFertser>
rolf: were your patches reviewed already? can you tell the numbers?
MGF_Fabio has joined #openocd
<rolf>
Sure
<rolf>
7983
<rolf>
and 7986
<PaulFertser>
rolf: on 7983 there's still one comment marked as unresolved, is it essential?
<PaulFertser>
rolf: I guess you should just ping Antonio here to get those patches moving.
<rolf>
Not highly essential, the code is utilized by Infineon and tested by a huge user-base. Only to get going in the OpenOCD branch, some advice may be needed, but not crucial in a way that the code doesn't perform well
<rolf>
I will ping Antonio, thanks!
<PaulFertser>
rolf: his nick here is borneoa___ (with varying amount of _)
<bvernoux>
rolf, good luck to have something merged in official openocd
<bvernoux>
I vote to rename OpenOCD to STOCD as >80% of things quickly merged are from ST
<PaulFertser>
If you read the devel mailing list you see people send mails about the changes they're interested in every now and then, and it helps to draw attention and merge eventually.
<PaulFertser>
Also, voting is better done on the mailing list too.
<zapb_>
bvernoux, ST pushes OpenOCD by one or two devs which is nice. However, there is no bias towards ST products in OpenOCD. Also, borneoa___ does a great job with lots of non-ST specific tasks like code refactoring cleanups etc, review etc.
<zapb_>
bvernoux, regarding your patch, I think it would be nice to introduce a general OS-agnostic layer for serial devices, or use something like https://sigrok.org/gitweb/?p=libserialport.git
<karlp>
(I think thomas is being a little overlyharsh that openocd shouldn't accept the latter though)
<zapb_>
karlp, thomas?
<karlp>
thomas? tvanek? have I always jsut assumed that?
<karlp>
could very well be. that might be just in my head.
<zapb_>
ah, tomas
<karlp>
right, yes, sort of close, but wrong on my half still.
<zapb_>
hm, I don't know his opinion on this topic but libserialport has no dependencies - should not hurt that much
<karlp>
no, I'm talking about the other patch, the flash driver for the "bad" part.
<zapb_>
ah, sorry
<karlp>
I have no opinion on windows support, not my thing and can't test it :)
<bvernoux>
The main issue is any PR take too much time and it is a dead end
<karlp>
no, they're not dead ends, they jsut don't ever merge as fast as you like.
<karlp>
that's not the same thing.
<bvernoux>
Does anyone here have asked themself why there is so much fork on github ?
<zapb_>
same here, but I think OpenOCD has at least a few Windows users :)
<bvernoux>
Because it is nearly impossible to merge something in official OpenOCD
<zapb_>
bvernoux, even libjaylink has many forks, that's no indicator :D
<karlp>
wel, espressif disagrees with you there, they're moving their own stuff up to upstream
<bvernoux>
Check some things like ESP32 and others which are very popular
<zapb_>
what karlp says :D
<bvernoux>
On my side I tried and it failed miserably and I have lost my time trying to push something on official openocd
<zapb_>
bvernoux, the espressif devs work on OpenOCD directly ;)
<bvernoux>
all the burden with review which go nowhere at end
<bvernoux>
I'm pretty sure it is easier to push a patch on linux than on OpenOCD
pedro_pt has quit [Quit: Client closed]
pedro_pt has joined #openocd
<zapb_>
You can push a lot of patches, if they get merged is the other question ;)
<bvernoux>
yes it is the question
<karlp>
by talos, have you seen how many forks of linux there are? that project must be completely dead.
<bvernoux>
it will be better to say do not push patch they will be never merged
<bvernoux>
like that guys like me will do not loose their time to try
<zapb_>
bvernoux, you did not even ping **once** for your patch on Gerrit
<bvernoux>
Gerrit is awfull
<zapb_>
Yep, I don't like it too
<zapb_>
but that's not the questions here
<zapb_>
You did not ping **once**
<bvernoux>
Gerrit is like doing Web with text only browser ;)
<bvernoux>
I have tried to ping here
<bvernoux>
I have tried to ask for other guys to review PR
<bvernoux>
nothing at end
<bvernoux>
I'm not sure this Gerrit stuff even support notification
<zapb_>
bvernoux, unfortunately I don't have this device, otherwise I would test it
<PaulFertser>
It sends e-mails on patch updates.
<zapb_>
bvernoux, but I gave you feedback for your patch
<bvernoux>
I have never seen any feedback except the one from Tomas Vanek which ask for some modifications and at end set -2
<bvernoux>
What a total joke
<bvernoux>
It seems this guy other loose time for nothing at end
<bvernoux>
+like other guy loose time
<zapb_>
bvernoux, sorry, a bit to late at the moment for a +1k patch ;)
pedro_pt has quit [Ping timeout: 250 seconds]
<bvernoux>
the main issue in the whole process
<bvernoux>
is that do not impact any other processor as it is a new one
<bvernoux>
so why everything is so complex
<bvernoux>
even if in worst case this MCU support will have any issue it will not affect anything except this MCU type which was not existing before anyway
<zapb_>
bvernoux, yes, it may not impact other devices. However, the code must be somehow maintainable and understandable
<zapb_>
But not sure what the problem is with your patch
<bvernoux>
seriously if you check it is trivial
<bvernoux>
even more for developer which work on OpenOCD since years
<bvernoux>
with no possible impact on any other stuff
<bvernoux>
except adding native windows support
<bvernoux>
even if it could be better with libserialport (which I clearly do not like)
<bvernoux>
I would say it is better than nothing
<zapb_>
bvernoux, your flash driver looks quite good (optical code inspection ;)). I think I would have to read the entire history in Gerrit and maybe the docs to understand the problem
<zapb_>
bvernoux, what's wrong with libserialport?
<zapb_>
bvernoux, if you don't like it or other devs are not willing to add is as dependency, write your own small layer of abstraction, then you get a +1 from me ;)
<karlp>
is that driver really the only place using serial ports?
<zapb_>
seems so
<zapb_>
just checked it
<bvernoux>
zapb_, i'm clearly not fan of the libserialport design
<bvernoux>
anyway it shall do the job it is just quite complicated mixing things with bluetooth, usb ...
<bvernoux>
calling 1 api per parameter is ugly
<bvernoux>
I have the feeling to see libopencm3 which I really hate when they use one function per parameter
<zapb_>
bvernoux, yes, maybe it is not the best choice but gives us not only Windows support but also Mac OXS and BSD
<bvernoux>
as everything could be so simple grouping some stuff to avoid all those API calls for nothing especially for the configuration stuff
<zapb_>
Anyway, not insisting on libserialport, but to have all the os specific code in at a different place would be nice and then I see no reason to not merge your patch
<bvernoux>
anyway it will requires a full rewrite of the original code
<zapb_>
Well, a bit of code copy/paste
<bvernoux>
and I have clearly no any spare time nor motivation to do that
<bvernoux>
I loose already so much time doing open source stuff ;)
<bvernoux>
Sometime I ask myself why as the one which use them "steal" the code for proprietary stuff in big company ...
<zapb_>
bvernoux, same for all other OpenOCD devs ;)
<bvernoux>
Yes it is why I was doing those PR to contribute for all the amazing work done freely by OpenOCD devs
<borneoa___>
bvernoux: maybe entering too late in the discussion. I haven't read all. I quickly checked 7805 and I find the #if/#else/#endif is not acceptable. I'm looking for removing them as much as I can from OpenOCD code. It needs better abstraction. I don't know libserialport, maybe it's a good option.
<zapb_>
bvernoux, as you probably know from other projects, contributing is almost never done by a single 'git push'
<bvernoux>
borneoa___, I can understand some people do not like the #if/#else/#endif it was just to do simple fix with as less as possible impact and simple code to review
<zapb_>
(afk, but still happy to review/merge your patch if you make the small changes in the buspirate driver)
<bvernoux>
zapb_, https://review.openocd.org/c/openocd/+/7804 was not a simple push but 17 Patchset and even a full rewrite using swm050.c which was a total fail in term of performance and border effect ...
<bvernoux>
just because Tomas Vanek does not like the "embedded algorithm for erase/program"
<zapb_>
bvernoux, I see and I would like to see this also merged but I don't have the target and do not understand the issue at the moment. For the buspirate driver I see that this can be merged soon
<bvernoux>
thanks for your effort anyway
<Hawk777>
bvernoux: I skimmed the discussion on that driver, and it looks like Tomas never actually said to get rid of all the target algos. He said you probably *should* use a target algo for programming, just not for erasing or probing.
<Hawk777>
Which makes sense! A target algo is usually only useful if there is a lot of data to move around fast. Erasing is just poking some registers and then waiting, so it doesn’t need one (usually).
<Hawk777>
And probing needs to avoid running a target algo because it overwrites memory that the application might have been using.
pedro_pt has joined #openocd
<bvernoux>
Hawk777, yes but read all you will see it is a total joke I have provided the other version with fact that it is not working fine and Tomas was still insisting ....
<bvernoux>
An example => To erase and program 12132 bytes it take less than 0.5s vs 21s => So 42 times faster
<zapb_>
Well, Tomas has a good point if that's correct. Probing should not be done by flash algo
<bvernoux>
Do you imagine it was on 12KB and the chipset is 64KB
<bvernoux>
the probing was changed after
<Hawk777>
You quoted time to erase *and program* without a target algo. That is irrelevant, if everyone agrees programming *should* use a target algo.
<bvernoux>
I the last patchset I have done all exactly like he want
<zapb_>
Erasing could be done with a flash algo and by OpenOCD as fallback - as for programming
<zapb_>
(my opinion)
<bvernoux>
for that particular target both was mandatory to be done with flash algo
<bvernoux>
as the cx32l003 is ultra slow and requires tons of step to write just a word
<zapb_>
I cannot imagine that Tomas is against erase flash algos, this is not that uncommon and "standard" for the ARM CMSIS-based flash algos
<bvernoux>
so doing that with target_write/read was awfully slow and have some big issues with the programming / erasing too as it break the debug ...
<bvernoux>
so it was a total mess which does not appears with program/erase flash algo
pedro_pt69 has quit [Ping timeout: 250 seconds]
<bvernoux>
My code is even more optimized and better than the one from the manufacturer
<bvernoux>
which is a blob provided only for Keil/IAR
<bvernoux>
I have even translated and checked the Chinese DataSheet to English to give the proof
<bvernoux>
I doubt you have often such type of contribution
<zapb_>
bvernoux, so you're saying the patch is blocked because you use the erase and program operation as flash algo only?
<bvernoux>
zapb_, I do not know but what I know is Tomas Vanke just quoted Code-Review -2 without any other comment at end
<bvernoux>
For me Patchset 17 contains all recommended modification for a merge
<zapb_>
bvernoux, well, ask on Gerrit what you have to change to get this patch merged please
<bvernoux>
pushed
<zapb_>
bvernoux, and fix your commit message ;P
<bvernoux>
see my last commentWhat do I need to change to have this Patch merged as I do not have any feedback since 05 Oct 2023 ?
<Hawk777>
Did you ever figure out why the non-algo erase implementation sometimes fails with SWD errors? You said it failed but you never explained why. This is just an idea, but maybe it would help convince people you need an erase algo if you can explain why the non-algo version fails (not just “oh I tried it and I got errors”, but actually investigate and say something like “when the Flash is erasing, this clock here in this diagram stop
<Hawk777>
s, therefore this bus stalls, therefore this fails”, something like that).
<bvernoux>
I have explained in detail why the non-algo fail
<zapb_>
Hawk777, +1
<bvernoux>
it have issue with the HW
<bvernoux>
as when we do step by step with non-algo the Debug is stopped
<zapb_>
bvernoux, how do you know? what kind of issues?
<zapb_>
this does not mean the hardware is broken, it could be that your code is wrong ;)
<Hawk777>
That’s just saying “it doesn’t work”. It’s not explaining *why* it doesn’t work.
<bvernoux>
in fact to avoid that we shall add ugly delay
<bvernoux>
so it is even slower at end
<Hawk777>
Which memory access fails? What kind of failure happens? Why does it fail? Is there a clock stopped? Is some bus busy? What is actually happening inside the chip?
<bvernoux>
Things like
<bvernoux>
SWD DPIDR 0x0bc11477
<bvernoux>
Failed to read memory and, additionally, failed to find out where
<zapb_>
bvernoux, does not matter, if the code is correct that's fine, in most cases you use the flash loader anyway
<Hawk777>
I think it is not possible that the whole SWD interface stops working while Flash is being erased. The reason is because your algo-based erase works. SWD is still being used while an algo is running (to check whether the algo has finished or not), so clearly SWD as a whole is working during erase.
<Hawk777>
So maybe it is a specific register that you cannot access during erase, or something like that.
<zapb_>
Hawk777, yap
<bvernoux>
yes I cannot poll the status of end of erase
<bvernoux>
and I need to add ugly delay
<bvernoux>
I have not find any other way with noalgo
<zapb_>
you cannot access via SWD but by the target?
<bvernoux>
yes acces over SWD during few seconds on some operation was not possible
<bvernoux>
especially erase or some program too
<bvernoux>
usually that shall not appears on lot of MCU but on this one it break SWD
<bvernoux>
dumped 65536 bytes in 0.845358s (75.708 KiB/s)
<bvernoux>
dump_image dump_64KB.bin 0 65536
<bvernoux>
I doubt we can improve that with a faster SWD probe as anyway the CX32L003F8 will probably do not work with SWD frequency >2MHz ...
<borneoa___>
Thinking about why the SWD stops. Probably there is one read or write to the flash controller that stalls the CPU and it's memory bus. CortexM debug bus is somehow connected to the CPU memory bus and maybe it stalls too. Probably polling a flash controller status bit could prevent using the read/write and avoid the stall.
<zapb_>
borneoa___, but polling the status registers breaks if I understood bvernoux correctly
<bvernoux>
yes
<bvernoux>
I need to do that
<bvernoux>
/* After flash erase sector command wait at least 10 ms
<bvernoux>
to avoid an error on target_read_u32() as bus is staled */
<bvernoux>
alive_sleep(10);
<bvernoux>
and also
<bvernoux>
/* After erase flash command wait at least 250 ms
<bvernoux>
to avoid an error on target_read_u32() as bus is staled */
<bvernoux>
alive_sleep(250);
<bvernoux>
and it is even possible that on some chip it will be not working
<bvernoux>
especially on aging flash
<bvernoux>
it could requires more time
<zapb_>
bvernoux, just added me as reviewer, please try to make clear (again) why non-flash-algo does not work for this target
<bvernoux>
just to be clear
<zapb_>
If this is really a problem of the chip I don't see any reason why we cannot merge this driver as-is (=with erase/program as flash-algo operations only)
<zapb_>
bvernoux, well, usually you have a max. time for flash erase operations provided by the manufacturer
<zapb_>
this should always work
<bvernoux>
On patchset 13 Sep 05
<bvernoux>
Tomas Vanek say: Please take me seriously: I really want you to remove all npcx based rubbish.
<bvernoux>
Putting -2 score until you submit a code based on your no algo version - the target algo (for faster write only) could be added later.
<bvernoux>
My answer
<bvernoux>
understand your point but actual "no-algo" version even if it is cleaner is too slow and have lot of border effects during erase/program algorithm done step by step with target_read_u32()/target_write_u32() especially after erase or programming command when we want to poll the status of the flash there is some SWD fatal errors which requires to add some arbitrary wait delay (alive_sleep()) which are very bad as it can break on
<bvernoux>
different MCU depending on flash aging... and that slow down even more the whole process which take more than 1minute when algorithm version take less than 2s...
<bvernoux>
dumped 65536 bytes in 0.845358s (75.708 KiB/s)
<bvernoux>
dump_image dump_64KB.bin 0 65536
<bvernoux>
I doubt we can improve that with a faster SWD probe as anyway the CX32L003F8 will probably do not work with SWD frequency >2MHz ...
<bvernoux>
so then the discussion continued on cleaning flash algo stuff
<bvernoux>
with fix on patchset 14/15/16 & 17
<zapb_>
bvernoux, have to go now, please write a short summary what is done, what could be implemented (non flash-algo with max. delays) and ask what do provide to get this patch merged
<Hawk777>
Crazy idea. Did you check the PC value when running the non-algo-based code? If it is somewhere in Flash, does the code start working properly (without the extra usleep) if you move the PC to point into RAM? It normally wouldn’t matter, but the chip must have an unusual visibility into PC if it is able to prevent erasing the sector that PC points into (which §10.3.5.2 claims it can).
MGF_Fabio has quit [Ping timeout: 264 seconds]
<bvernoux>
The PC value depends on previous sw loader in flash on non-algo-based
<bvernoux>
but yes it is in flash
<bvernoux>
It is why the algo version is mandatory to have a clean state and to run the algo in RAM
<Hawk777>
I am saying, if you change the PC to point somewhere in RAM before doing the non-algo version, would that make any difference? Would it eliminate the errors and allow you to remove the sleeps?
<bvernoux>
the effect was it was not possible to poll flash state from SWD
<bvernoux>
so I doubt that will change anything if PC is in RAM or Flash for that
<bvernoux>
as SWD stuff are at an other level
<bvernoux>
Do you have read the hint how to retrieve code/data from protected flash on STM32 ?
<bvernoux>
it is because of a trick with SWD to bypass the protection and read 1 byte anywhere in flash
<Hawk777>
Normally I would agree with you, except that §10.3.5.2 claims that the hardware actually compares PC to sector addresses and prevents you from erasing the sector in which you are executing.
<bvernoux>
that clearly show ARM SWD is at a lower layer than normal code execution in flash as it is capable to take hand on exception ...
<Hawk777>
So therefore the Flash hardware has some kind of view of the PC register which it would not have in normal MCUs.
<Hawk777>
There could therefore be a hardware effect that depends on the value of PC, *even when code is not executing* (because it’s debughalted).
<bvernoux>
I suspect target_write_u32 and target_read_u32 change that
<bvernoux>
to be checked
<Hawk777>
I don’t think I have read that note, and I don’t see what it has to do with anything since we are not talking about STM32 here.
<bvernoux>
as they are using special stuff
<Hawk777>
No, target_{read,write}_u32 do not modify PC in order to work.
<Hawk777>
IIRC they do memory accesses directly from the MEM-AP.
<Hawk777>
OK, but that is not the same case—it is not in RAM.
<bvernoux>
it was disable for final script
<Hawk777>
So it is still possible it could behave differently.
<bvernoux>
as for algo all states are clean
<bvernoux>
yes no-algo could have such issue depending where is the PC
<Hawk777>
Programming should be done after “reset init” so ideally PC should be whatever it takes at powerup.
<Hawk777>
Assuming reset is working right.
<bvernoux>
there is no reset unfortunately
<bvernoux>
by default it is not used
<Hawk777>
But still, that is different from what it would be for algo. Algo would have PC pointing into RAM rather than whatever its initial state is.
<bvernoux>
yes algo could not have strange effect because of that I agree
<Hawk777>
You mean reset doesn’t work? That sounds like a bigger problem which might be worth solving first. Even if there is no SRST pin, does AIRCR-based reset (which would be used in the absence of SRST) not work?
<bvernoux>
it was the last version which was working
<Hawk777>
I skimmed the code a little.
<bvernoux>
with workaround using some alive_sleep()
<bvernoux>
if the PC was in flash forbidden it will never work even with those alive_sleep
<bvernoux>
and it works
<Hawk777>
That is not true.
<Hawk777>
It could be that, with PC pointing into Flash, accesses to FLASH_CR stall, but with PC pointing into RAM, they complete immediately. If that is the case, then with the sleep it would work because you don’t access FLASH_CR until after the erase/write op finishes.
<Hawk777>
Also, if you don’t have reset working, are you absolutely certain that the CPU is actually halted properly when you run your no-algo code?
<bvernoux>
it is checked
<bvernoux>
in lot of parts of code
<bvernoux>
if (target->state != TARGET_HALTED) {
<bvernoux>
LOG_ERROR("Target not halted");
<bvernoux>
return ERROR_TARGET_NOT_HALTED;
<bvernoux>
}
pedro_pt has quit [Quit: Client closed]
<Hawk777>
That checks whether OpenOCD *thinks* the target is halted. But have you checked if the target is *actually* halted? If reset is broken, maybe that information is incorrect. TBH if I were working on this I would probably try to fix reset first.
<bvernoux>
Reset Pin is not available in fact by default
<bvernoux>
so it is the standard way to use it without the Reset Pin
rolf has quit [Remote host closed the connection]
<Hawk777>
I didn’t say the reset *pin*. I said reset, which can be accomplished in many ways: with the reset pin, with AIRCR, and probably some others.
<bvernoux>
and so yes algo again is mandatory for that too, to avoid border effects
<Hawk777>
No, writing into AIRCR can be done without a target algo.
<bvernoux>
reset what done by SW
<Hawk777>
It’s just a memory location.
rolf has joined #openocd
<borneoa___>
There is also a SW reset command for CortexM
<bvernoux>
it was the only way to reset the whole MCU
<Hawk777>
Does that even work? If that is in an ordinary config file, you can’t use “mww” during init phase, only after the implicit “init” command has run (which normally happens after all config files have loaded) I think.
<bvernoux>
using
<bvernoux>
he chip can be reset by writing MCURST and CPURST of RCC_RSTCR register
<Hawk777>
Anyway I am not talking about resetting the target once when OpenOCD starts. I am talking about making the overall reset infrastructure work properly so it can reset whenever it needs to.
<bvernoux>
Like explained I test the MCU on E220-900T22D
<bvernoux>
the main purpose was to fully reverse the E220-900T22D and re-program the Zbit CX32L003F8 MCU inside
<Hawk777>
It looks like you are writing the wrong value to RCC_UNLOCK. The manual says 0x2AD5334C not 0x55AA66990
<bvernoux>
to have a low power MCU with LoRA
<Hawk777>
Sorry, not 0x55AA6699.
<Hawk777>
Unless that value is meant to be shifted.
<Hawk777>
Maybe they mean that is the value of only bits 31:1, in which case that is OK.
<bvernoux>
you shall read it
<bvernoux>
Writing 0x156A99A6 (0x55AA6699>>2) is valid. Writing other values has no effect
<bvernoux>
the bit 0 & 1 are MCURST & CPURST
<Hawk777>
I am not talking about RCC_RSTCR, I am talking about RCC_UNLOCK.
<Hawk777>
Anyway, probably it is fine, probably they are talking about 31:1 instead of 31:0.
<Hawk777>
But still, why can’t you just use normal AIRCR?
<Hawk777>
Which probably OpenOCD will already use internally for resets?
<Hawk777>
(not 100% certain)
<bvernoux>
I do not remember I have done so much test on that crap
<bvernoux>
no-algo was not reliable
<bvernoux>
and algo was fast and reliable 100% of time
<bvernoux>
doing tons of test with it
<Hawk777>
But you don’t understand why.
<bvernoux>
The only fact it take 66s to erase/program 64KB is a blocker issue for me
<bvernoux>
when the algo take less than 2s
<Hawk777>
I will say it again: Tomas did *NOT* ask you to stop using algo for programming! Only for erasing! Erase speed should normally not depend on using an algo, because there is so little data movement.
<bvernoux>
Why to push that slow crap full of stranger effect with no-algo when algo is robust and safe without border effect running in RAM too
<bvernoux>
The issue is erase was also ultra slow in no-algo
<Hawk777>
Only because you added a big sleep.
<bvernoux>
and not reliable
<bvernoux>
no without the sleep of 250ms it was not reliable and also very slow when it worked
<bvernoux>
250ms is nothing vs >20s
<Hawk777>
“It was not reliable” ← *and you don’t know why*!
<bvernoux>
mainly because I cannot reset the MCU like I want in a clean state too
<Hawk777>
Maybe you should fix htat.
<bvernoux>
which was not a problem on the algo as all was set correctly during algo init in RAM
<bvernoux>
fix that to have performance of >60s to erase/program 64KB ?
<bvernoux>
vs 2s with algo ?
<bvernoux>
who want that seriously
<Hawk777>
Why do you keep saying this over and over and over again?
<Hawk777>
Stop talking about erase+program time.
<bvernoux>
when you are erasing/programming such type of MCU all the days for lot of tests you will understand
<Hawk777>
If you want to talk about erase time, talk about erase time. If you want to talk about program time, talk about program time.
<Hawk777>
They are separate.
<bvernoux>
even one time with no-algo the flash was like locked
<bvernoux>
I was not able to erase it anymore
<bvernoux>
and I switched to algo to cleanup that mess
<bvernoux>
so yes no-algo is not robust and full of bad effect in addition to extreme slowness on that MCU
<bvernoux>
with no-algo program time was the worse especially to set registers requires to program word by word
<bvernoux>
but sector erase was also as slow
<bvernoux>
only the mass erase is fast is it requires only basic step to fully erase the whole chip
<Hawk777>
Why? Why was sector erase slow? What part of it was slow? It is doing very little work. Did you profile it to find out which part is taking a long time?
<bvernoux>
just check the code of cx32l003_flash_erase_sector for no-algo you will understand
<Hawk777>
You did not answer my question. I am looking at that code. It does not look like it should be slow. Did you find out WHICH PART is slow and WHY?
<bvernoux>
it requires lot of steps with target_write_u32/target_read_u32
<Hawk777>
That is not slow.
<Hawk777>
A few dozen words of memory access is not slow.
<bvernoux>
it was very slow on that MCU
<Hawk777>
It shouldn’t be.
<bvernoux>
each target_read_u32 take few ms
<bvernoux>
it invloves tons of SWD cycles behind
<bvernoux>
with a 2MHz default clock
<Hawk777>
OK, so a few dozen milliseconds per sector, times eight sectors, is still only a small fraction of a second.
<bvernoux>
doing that on 128 pages is ultra slow
pedro_pt has joined #openocd
<Hawk777>
Where did the 128 pages come from? The manual you shared said the chip has 8 sectors.
<bvernoux>
there is 128 pages of 512bytes per page