Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Scripts to support Atmel SAM3 chips
#11
e.g. samd21g17

Well, I kept your code for the M3 cores and mine for the M0 cores.

The code base used for the scripts is in github (https://github.com/EmBitz/EBlink-scripts ) you could do pull request here also. Perhaps we should start a dev branch.
Reply
#12
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.
Reply
#13
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.
Reply
#14
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.
Reply
#15
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.
Reply
#16
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".
Reply
#17
(28-04-2023, 04:33 PM)jdubois Wrote: does your API offer access to the SW-DP registers?

So I found that the interfAPI class has members called setDapAp, getDapAp, readDap, & writeDap.  SetDapAp and GetDapAp are self explanatory and seem to work as intended.  But I can't quite figure out readDap and writeDap.  I know readDap takes (at least) two parameters, but I don't know what they are.  Any insight?
Reply
#18
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.
Reply
#19
Can you give some feedback about those two commands if they are working or not?
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)