How to program CY8CKIT-059 using PSoC Programmer CLI?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
koczis
Level 2
Level 2
10 replies posted First like given 5 sign-ins

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.

0 Likes
7 Replies
ScottA_91
Employee
Employee
10 solutions authored 100 replies posted 50 replies posted

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.

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.

0 Likes
ScottA_91
Employee
Employee
10 solutions authored 100 replies posted 50 replies posted

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.

0 Likes

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.

0 Likes
ScottA_91
Employee
Employee
10 solutions authored 100 replies posted 50 replies posted

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.

> 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.

0 Likes
ScottA_91
Employee
Employee
10 solutions authored 100 replies posted 50 replies posted

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).

0 Likes