<ALTracer>
PaulFertser: yep, the service took down 25 kb of text for some reason
<ALTracer>
I did click the "contact us" link and explained what the contents are, yesterday
<zapb__>
ALTracer, you need the lookup table if you want to support features like USD (including the 'real' user data area)
<PaulFertser>
ALTracer: probably just paste it elsewhere and it's not like all 25 kB are important, it's probably repeating some poll after "reset halt" fails and that's not useful for analysis.
<zapb__>
ALTracer, if you have another idea how to determine the size let me know
<ALTracer>
PaulFertser: which service do you suggest then?
<PaulFertser>
I usually use paste.debian.net
<zapb__>
ALTracer, the table does not include dual-bank devices on purpose
<PaulFertser>
And imgbb.com for images.
<ALTracer>
zapb__: USD/OB size is tied to flash page size and product family, and like every 7 parts behave identically even though they have different packages (pin count)
<ALTracer>
zapb__: What purpose?
<zapb__>
ALTracer, where do you get this information from?
<zapb__>
ALTracer, there are part with same USD size bit different flash and page size
<zapb__>
+s
<zapb__>
s/bit/but
<ALTracer>
zapb__: Arterytek reference manuals for ~10 chip families, which I downloaded to carefully navigate product feature sets to add support to BMD.
<zapb__>
ALTracer, okay, USD is *not* tied to flash page size
<PaulFertser>
ALTracer: reading https://paste.jvnv.net/view/5zd8Q I'd say probably it needs more time _after_ deasserting SRST, as if the target isn't ready to talk to the debugger.
<zapb__>
ALTracer, show me the algo / relation and I'm happy to adapt it
<PaulFertser>
Is it the same with "adapter srst delay 1000" ?
<ALTracer>
zapb__: unfortunately Arterytek did not make it that easy for debugger developers, and I have only seen one appnote which describes detection by PID+UID
<ALTracer>
Oh, supporting AT32F405/F402 is a potentially low-hanging fruit, its FPEC behaves like F435/F437, was that left out for a follow-up because you don't have a board with it to test on?
<zapb__>
ALTracer, where do I see the usd size detection?
<zapb__>
ALTracer, I see a switch-case for packages and flash size detection
<zapb__>
ALTracer, this code does not support 512B and 4 KiB sizes of F435/F437 devices?
<ALTracer>
the calloc for 4 kilobytes was prone to failing on constrained BMP heap for unrelated reasons
<ALTracer>
It should support 256 pairs and 2048 pairs, that is 512 bytes and 4096 bytes, I was only able to test on 4 KiB size device, F437ZMT7
<zapb__>
ALTracer, you're talking about double the size because of inverse values?
<ALTracer>
Yes, option bytes always come with inverses/complements.
<zapb__>
ALTracer, what about the 1 KiB devices then?
<zapb__>
F415
<ALTracer>
I admit I haven't got around to refactoring the rest of it and splitting out code from stm32f1.c such that 48 byte and 512 byte devices get USD support because v2.0 release freeze is ongoing and I ran out of time
<zapb__>
Okay, you're saying there is a system that you know for all devices, then it turns out that not even entire device series is supported
<ALTracer>
I am saying the system should not require a hundred per-part LUT entries, that takes a lot of BMP code size, but I haven't implemented the entirety of it myself yet
<ALTracer>
especially as I only have two specimens, not entire lineup, to test on
<zapb__>
ALTracer, okay, first things first: this is OpenOCD - I don't care about BMP
<ALTracer>
It is a sort of dictionary on PID prefix plus blocksize, much smaller that complete PID
<ALTracer>
Of course, desktop space is relatively unlimited
<zapb__>
there is at least one entire device series that is not supported by BMP which does not fit into your system
<zapb__>
Yes, I can make a lot of if-statements to catch all corner cases
<zapb__>
Makes the code ugly to maintain and understand
<ALTracer>
I respect you as an embedded developer and code author of a functionally complete and tested working PR
<ALTracer>
You are free to ignore all of my thoughts
<ALTracer>
We'll see if I can revisit both implementations when I get around to that third refactor and treat all USD stuff
<zapb__>
If there is a simple system, let me know I'm happy to implement it this way but please don't make statements about 10+ devices series and the second series I take a look is not supported at all
<ALTracer>
Simple system in LUT form? Mask out three lower nibbles of PID and pair it with blocksize then use that as a key into LUT?
<ALTracer>
The forest of branches was a compromise to please the optimizing compiler and get smaller code of driver, it's not as readable as it could be in a different paradigm, you're right
<zapb__>
ALTracer, a simple system that let me determine all parameters I need
<zapb__>
ALTracer, for you it works at the moment because you don't care about USD size in all cases
<zapb__>
ALTracer, there might be system to also determine it, I don't you, you don't obviously but if it's simple and universal let me know
<ALTracer>
Arterytek's own AN0016 is not nearly enough complete for that...
<zapb__>
ALTracer, even AT's own openocd driver is not able to determine the USD size for all devices
<zapb__>
ALTracer, maybe there is no system I don't know but then this LUT is the only way to determine it
<zapb__>
ALTracer, where do you get this AN0016 from?
<ALTracer>
AP Note, search for "Recognize AT32 MCU" or a substring of that
<zapb__>
ALTracer, thanks, got it
<zapb__>
ALTracer, quite outdated though
<ALTracer>
I suppose AN0020 Getting started with AT32F403 (not AN0023 for F403A/F407) has another kind of table approach
<zapb__>
Revision says something about "added AT32WB..." but there is not AT32WBxx in the table :D
<ALTracer>
Arterytek engineers only roll a fork of OpenOCD to ship prebuilt binaries in AT32IDE, last year they also started relying on Segger JLink support and flashloader algorithms
<zapb__>
Yep, I know
<ALTracer>
*nobody* ever contacted or reacted BMD with notes on how flash support must be implemented
<zapb__>
ALTracer, BMP is even more niche than OpenOCD, no? ;)
<zapb__>
ALTracer, don't see a table in AN0020...
<ALTracer>
It is niche but it runs on most any stlink clone
<ALTracer>
"Reading PID/UID", there are only two entries
<zapb__>
ALTracer, sure, not important for big chip manufacturers ;)
<ALTracer>
That is an impression I've got over two years, too. A community effort.
<ALTracer>
ST at least cares somewhat about OpenOCD.
<zapb__>
ALTracer, don't get me wrong, I'm not saying a big LUT is the best solution, it's simple, easy to understand and at the moment the only way to have information about USD size for all devices without if-statements etc.
<ALTracer>
In this project I'm not against it, it is likely the best solution, just not directly portable to 120 KiB gdbservers
<zapb__>
ALTracer, yep, but time is limited and I cannot take care of other projects as well
<ALTracer>
I did have a go at fighting GCC for lpc546xx switch-case vs. LUT, it was inconclusive
<zapb__>
ALTracer, another benefit is that we have part name lookup, which is quite nice for some use cases
<ALTracer>
zapb__: You're already nice enough to mainline this part and I think you're not employed by Arterytek :)
<zapb__>
ALTracer, not at all
<ALTracer>
Part name lookup was another feature I agreed to drop / not implement for code size constraint reasons, yes
<ALTracer>
For the two "review" items I do not *require* a code change, just a text response. There's no -1 from me, my reviews don't hold weight, I am not a maintainer (or even a contributor) to OpenOCD
<ALTracer>
However I did express curiosity what your driver does on a device with WDT autostarted per USD. It performs direct register manipulation, not flashloader stub launches?
<zapb__>
ALTracer, in any case, you made enough of a fuss that i briefly questioned my implementation again ;)
<zapb__>
ALTracer, the watchdog behaviour is indeed a very good point
<ALTracer>
Therefore chip processing element stays in Debug state and DEBUG_CTRL freeze can be useful, even if it's two variants (F437 and F405 are special)
<zapb__>
I think it works at the moment because there is no flash loader involved
<ALTracer>
Reinforcing choices with technical arguments is a good enough impact :)
<ALTracer>
Arterytek fork fails to freeze WDT because they copypasted the Tcl hook for F437 and that is wrong
<ALTracer>
My merged PR does it properly, but you don't need to look at it to understand, refman contains enough info
<zapb__>
ALTracer, yes, you're right but unfortunately my time is so limited that it is even hard to push all my WIP patches to Gerrit / into the review process
<ALTracer>
Would you like me to make more fuss about WDT on PR8668?
<ALTracer>
just so it isn't forgotten or something
<zapb__>
ALTracer, please drop a comment about it or provide a patch / fix
<zapb__>
ALTracer, in case there is a different behaviour across the series, maybe we have to split the target configs
<ALTracer>
PaulFertser: I haven't tried inserting delays post SRST, but because TAP SM changes states, I don't believe a delay is useful -- a TLR sequence instead solves it, which is why I sent three pastebins. Have you looked at tails of them?
<ALTracer>
BMD maintainer agreed that doing that sequence won't hurt, it just wasn't implemented yet (BMP does not expose a TRST pin)
<ALTracer>
Anyway, thank you zapb__ for dedicating some of your limited time to review feedback, I hope it was not completely wasted for no use
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #openocd
<PaulFertser>
ALTracer: JTAG state machine is normally decoupled from ARM ADI debug unit.
<PaulFertser>
So yes, we see JTAG level state changes but it doesn't mean the debug circuity is ready to talk to OpenOCD. There's a chance TLR is just adding a delay.
<ALTracer>
PaulFertser: key word decoupled.
<ALTracer>
erm, normally.
<PaulFertser>
Well, adding delay is certainly needed by /some/ targets, and I do not think we have any in tree that needs additional TLR.
<ALTracer>
RM0436 for STM32MP157: When the TAPSM is in the Run-Test/Idle state, no special actions occur. The IDCODE instruction is loaded in IR.
<ALTracer>
If my suspicion is correct, and SRST on AT32F403A also pulls TRST, resetting IR from DPACC to IDCODE, then something is needed, but I don't know what exactly.
<ALTracer>
> The NJTRST signal when active resets the state machine asynchronously to the Test-Logic-Reset state.
<ALTracer>
`adapter srst delay`? Looks like it should be easy to try...
<PaulFertser>
Yes, external TRST signal should be equivalent to TLR according to the JTAG spec.
ALTracer has quit [Ping timeout: 268 seconds]
ALTracer has joined #openocd
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #openocd
Hawk777 has joined #openocd
Hawk777 has quit [Quit: Leaving.]
ALTracer has quit [Read error: Connection reset by peer]