- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Got the CYCKIT-059: https://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-on...
with KitProg1 clung to it like terrified kitten to a pantleg ...or perhaps the other way.
PSoC Programmer GUI works great... now... I need to automate this process as simply as possible.
I dug into the CLI doc, but it's apparently extremely superficial even regarding command descriptions.
I'll express myself using a partial example.
Consider following script (I paragraphed it for clarity):
---
version
GetPorts
OpenPort KitProg/1625073A00087400 "C:\\Program Files (x86)\\Cypress\\Programmer"
GetProgrammerVersion
GetProgrammerRevID
GetProgrammerCapabilities
GetPowerVoltage
SetProtocol 8
DAP_AcquireChip
DAP_GetJtagID
PSoC3_GetFlashArrayInfo 0
PSoC3_GetFlashArrayInfo 1
PSoC3_GetFlashArrayInfo 2
PSoC3_GetFlashArrayInfo 3
PSoC3_GetFlashArrayInfo 4
PSoC3_GetEccStatus
HEX_ReadFile "C:\\Doc\\Cypress\\CY8CKIT-059\\CY8CKIT-059 PSoC 5LP Prototyping Kit Code Example\\Hex Files\\CE195352_Blinking_LED.hex"
HEX_ReadJtagID
HEX_ReadImageSizes
HEX_GetRowsCount
HEX_GetRowAddress 0
DAP_ReleaseChip
ClosePort
quit
---
and it's output:
---
version
<version 3.28.0
1 OK
GetPorts
<KitProg/1625073A00087400
0 OK
OpenPort KitProg/1625073A00087400 .
<
0 OK
GetProgrammerVersion
<KitProg Version 2.21
0 OK
GetProgrammerRevID
<0x00000011
0 OK
GetProgrammerCapabilities
<0x0001-0x0006-0x0001-0x0000-0x000c-0x0000
0 OK
GetPowerVoltage
<3.3
0 OK
SetProtocol 8
<
1 OK
DAP_AcquireChip
<
0 OK
DAP_GetJtagID
<2e 16 10 69
0 OK
PSoC3_GetFlashArrayInfo 0
<0x00000100
0x00000100
0x00000001
0 OK
PSoC3_GetFlashArrayInfo 1
<0x00000100
0x00000100
0x00000001
0 OK
PSoC3_GetFlashArrayInfo 2
<0x00000100
0x00000100
0x00000001
0 OK
PSoC3_GetFlashArrayInfo 3
<0x00000100
0x00000100
0x00000001
0 OK
PSoC3_GetFlashArrayInfo 4
E0x01051e2f
0x01305760
0x0105276d
ArrayID parameter is out Flash arrays' range
PSoC3_GetFlashArrayInfo 4 returned 80004005
80004005 OK
PSoC3_GetEccStatus
<0x00000000
0 OK
HEX_ReadFile "C:\\Doc\\Cypress\\CY8CKIT-059\\CY8CKIT-059 PSoC 5LP Prototyping Kit Code Example\\Hex Files\\CE195352_Blinking_LED.hex"
<0x00040000
0 OK
HEX_ReadJtagID
<2e 16 10 69
0 OK
HEX_ReadImageSizes
<0x00040000
0x00008000
0x00000000
0x00000004
0x00000004
0 OK
HEX_GetRowsCount
<0x00000000
0 OK
HEX_GetRowAddress 0
E0x01051e2f
RowID parameter is out of range for Flash Array
HEX_GetRowAddress 0 returned 80004005
80004005 OK
DAP_ReleaseChip
<
0 OK
ClosePort
<
0 OK
<
0 OK
<OK
---
I have following questions:
1. Why output from "SetProtocol 8" is "1 OK" indicating an error? When I don't issue it I'm getting protocol mismatch errors.
2. Is there any command to get FLASH arrays no. for "PSoC3_GetFlashArrayInfo", not to have to cross the max index?
3. Why after loading the proper default example HEX for this kit "HEX_GetRowsCount" returns 0 and "HEX_GetRowAddress" errors no matter for what arg?
AND the most important:
4. What to do after loading that HEX to actually program it into the target's FLASH??
Please notice, I don't want to overwrite the KitProg! I understand that I have to somehow ask the KitProg to update the target.
Thanks in advance for any tips.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So first, unless you put the kit prog into bootloader mode, you will not overwrite it. (I believe this is done by holding the button while plugging in, so just don't do that.)
Second, you might want to look at the examples in:
C:\Program Files (x86)\Cypress\Programmer\Examples\Programming\PSoC3_5 (look at the readme)
C:\Program Files (x86)\Cypress\Programmer (look at PSoC35_CLI_Ex.pl)
for an idea on how to program a chip with your hex file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, although I don't really like to be redirected to examples and prefer sound docs, your post made me dig more into them.
My observations:
- this isn't really PSoC Programmer CLI, because CLI means the headless/text-only interface to exactly SAME app functionality, instead, this is low-level COM routines access interface
- there's no proper documentation of these COM objects, just a comprehensive basic method USAGE listings
- regular C# access is most polished and complete, while other may be deficient or lack methods, e.g. you can't keep or process return/out values in CLI and it lacks the very important 'PSoC3_GetSonosArrays' procedure (among others)
.
My next questions:
1. Since the lack of 'PSoC3_GetSonosArrays' in CLI indeed answers my previous question 2., in your opinion is CLI access discouraged and C#/VB/etc. access preferred?
2. There's that "ProgrammerLibrary.dll" and an example for it at "Cypress\Programmer\Examples\Programming\PSoC3_5\SWD\C_Sharp_Lib". Is there ANY doc for this library? Especially for "programLib.Program()" method and which devices/algorithms it handles?
Finally, I'd like to complain about the lack of true PSoC Programmer CLI and/or automation through cmd-ln opts or scripting (even in GUI). If there's 'runfile' cmd in pseudo-CLI, why not script this thing thoroughly? I encourage Cypress to design and implement a consistent cmd-ln/script/CLI access.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Frankly, almost no one ever uses the PPCLI. Either they use the GUI, program via a standard like JTAG, or supply Cypress with an image to put on the chips they are buying (provided they are buying enough chips).
As for the com interface, yes the C# is more developed. Creator is written in C#, so it is using those interfaces for programming/debugging.
Finally, going forward, programming will be done through OpenOCD (for P6 + ModusToolbox). So I wouldn't expect many changes to PSoC Programmer going forward.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, got it.
Anything regarding my 2nd question - the ProgrammerLibrary ?
It looks promising - all hi-level stuff may already be done in that single method, at least for some targets.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would use:
C:\Program Files (x86)\Cypress\Programmer\Examples\Programming\PSoC4\SWD\C_Sharp_Lib\C_Sharp_Lib
as PSoC4 is newer than PSoC5 and that example appears to support kitprog.
If you diff that with the P3/P5 example, you'll see there's only a couple of differences (related to voltage or looking for DVKPROG vs KITPROG) so I *think* that this is your high level library for programming (at least for any chip using kitprog).
The thing is here, while a lot of this seems chip specific, it really shouldn't be. It is programmer chip specific. Basically you're trying to talk to the programmer chip and just give it a standard stream (hex) to program to the chip via a standard interface (jtag/swd).
Edit:
Cleared up a little language.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> PSoC4 is newer than PSoC5
>
HUH? I'm pretty convinced it's the other way - PSoC4 is Cortex-M0/M0+, whereas PSoC5 is M3.
But OK, I understand there are no docs for ProgrammerLibrary and that PSoC4 example is the nearest available, because it checks against "KitProg" string.
I already tried learning something by disassembling this lib and other assemblies, but they're too complicated for me to go on that way and I don't have time to spare for trial and error.
I think this concludes my topic then.
Thanks a lot ScottA_91 - you rather confirmed my anxiety about it, but anyways it was helpful and I'm now sure I ain't gonna follow my original subject, but use some .NET lang approach.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes the contents of the hex file are different for the different architectures, but the programmer doesn't care. It just sends data over SWD to the device via a specific set of hardware (in this case the KitProg).