Posts: 22
Threads: 5
Joined: Oct 2021
Reputation:
0
Weird. I tested it with a samd21g18 which should have an almost identical ID. I'll take a look to see where I might have gone wrong.
Good idea on the dev branch. I've been adding some more chips to the NXP scripts but didn't want to inundate the forum with every little change. But I could certainly send pull requests to the dev branch.
Posts: 246
Threads: 14
Joined: Apr 2020
Reputation:
16
And is that g18 detected by my code? I only have a g17 and g15 here to test.
The 'dev' branch is just added to github.
Posts: 22
Threads: 5
Joined: Oct 2021
Reputation:
0
I looked at your updated auto.script and atmel-auto.script and it seems to do the trick to avoid the false positives in the atmel script. The only thing I did notice was that the new auto.script very slightly broke the nxp-auto.script. Just need to change the function findLPCDevice() in the nxp-auto.script to findDevice() (and the call to it in the main() function) and everything now seems to flow beautifully from the auto.script for NXP, ST, and Atmel chips (I don't have any silabs chips to test).
I'll put up a pull request on the dev branch after I've added a few more devices to the NXP detection.
Posts: 246
Threads: 14
Joined: Apr 2020
Reputation:
16
27-04-2023, 06:49 PM
(This post was last modified: 30-04-2023, 06:50 PM by embitz.)
Great! Thanks.
About that findDevice vs findLpcDevice, I saw it but didn't recognised it as wrong. Only now when you mentioning it.
The whole idea is that every vendor specific auto script can be used as standalone as well as with global auto script. EmBitz interface Dialog lets you chose between those scripts. ( I know that you are familiar with this but this is for the audience who are following this thread). EmBitz scans for all avaliable scripts and will let you chose in a drop down list.
Posts: 22
Threads: 5
Joined: Oct 2021
Reputation:
0
Yep, I like the way you've done that. The auto script should just work, but if it doesn't you can always select your vendor specific script. I was looking at the Cyprus (Infineon) chips, and I don't see any way to ID the chip as Cyprus if you don't already know. If that's true, you'd never be able to include them in a generic auto script.
Speaking of that, does your API offer access to the SW-DP registers? I'm curious about the IDCODE register and how useful that would be for identifying individual chips. I think the answer is "not reliably".
Posts: 246
Threads: 14
Joined: Apr 2020
Reputation:
16
17-05-2023, 07:46 AM
(This post was last modified: 17-05-2023, 08:01 AM by embitz.)
When I was busy with answering this question I found an inconsistency which will be solved next release. I will build a quick test version for you. I PM you a link.
int readDap(uint16_t ap, uint16_t addr); // The value is in InterfAPI.value32, return value is result which is also available at InterfAPI.result.
int writeDap(uint16_t ap, uint16_t addr, uint32_t value ); // Return value is InterfAPI.result
Remark: result is not the actual answer but the response code (error) of the action.
I copied these functionality from openOCD for the stlink but I never used or tested it yet.
BTW
What would you think of starting an open stlink firmware project? If we have an USB-API compatible firmware we could add special commands and also flash it in the STlink V3 to make this also workable for other vendors.
Posts: 246
Threads: 14
Joined: Apr 2020
Reputation:
16
Can you give some feedback about those two commands if they are working or not?
