- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
I am using document 002-22328 rev G to program a virgin CYBLE-022001-00 module. The steps have worked up to the erase entire chip step which is failing at the PollSronStatus() call (Step 3 - erase all flash at the top of page 28).
But what got me wondering is the use of the various symbols to formulate Params values. Usually fields & symbols like these are manipulated when they are individual fields/bits in registers. But in this instance and throughout this document many of the fields seem to overlap each other. For example, the statement at the top of page 28, in the erase all flash routine:
Params = (SROM_KEY1 << 0) + ((SROM_KEY2+SROM_CMD_ERASE_ALL) << 8); evaluates to
= ( 0xB6 ) + ( ( 0xD3 + 0xA ) << 8
= 0xDD00 + 0xB6
= 0xDDB6
Is this really what was intended here? Is seems as if SROM_KEY2 and SROM_CMD_ERASE_ALL are intended to be in different bit field locations from each other rather than being combined as they are. Are these definitions of these registers in another document that might clarify this?
Here's a trans script of my steps after the chip is "open":
Chip unprotected
writeio(20000100,DDB6): acl1 1, ack2 1
writeio(40100008,20000100): acl1 1, ack2 1
writeio(40100004,8000000A): acl1 1, ack2 1
readio(40100004,A): acl1 1, ack2 1, ack3 1
readio(40100008,F0000012): acl1 1, ack2 1, ack3 1
pollsromstatus()=failed
Can't erase flash
Scott
Solved! Go to Solution.
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue was due to length of the cable being longer causing delays that affected the SWD timing specifications. Solved by using a shorter cable around an inch long.
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No one has any thoughts on this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Scott,
The mentioned document (spec# 002-22328 rev G) is the programming spec for CCGx (CYPDxxxx).
I think you should try to use the following document to program your CYBLE-022001-00 module - https://www.cypress.com/file/409516/download .
Regards,
Apurva
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Apurva,
Scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Apurva,
I reviewed the document you sent me and it has not made any difference in the issue I am having. All the commands and procedures in the new document are the same as the document I originally consulted.
I am following the programming roadmap and it appears I am getting an error for the CPU's clock frequency not being set to 48 MHz before attempting to erase flash -- in spite of issuing the commands to change the frequency.
Here's a transcript of the commands and responses I am sending to the CYBLE-022001-00 module:
Found ID Hi 0E Low 50 Family 11
File checksum is A0BD, calc A0BD
ACK 1 ID BB11477
debug port configured
test mode entered
test mode confirmed
SROM PRIVILEGED bit cleared
** set clock to 48 MHz **
writeio(40100008,E8B6): acl1 1, ack2 1
writeio(40100004,80000015): acl1 1, ack2 1
readio(40100004,40000015): acl1 1, ack2 1, ack3 1
readio(40100008,A0000000): acl1 1, ack2 1, ack3 1
pollsromstatus()=A0000000 (OK)
** read module ID **
writeio(40100008,D3B6): acl1 1, ack2 1
writeio(40100004,80000000): acl1 1, ack2 1
readio(40100004,4000109E): acl1 1, ack2 1, ack3 1
readio(40100008,A0190E50): acl1 1, ack2 1, ack3 1
pollsromstatus()=A0190E50 (OK)
readio(40100008,A0190E50): acl1 1, ack2 1, ack3 1
readio(40100004,4000109E): acl1 1, ack2 1, ack3 1
Hi ID 0E, low ID 50, Rev 19, family 9E
Acquired
File ID matches Cypress module, program ? y
readio(FFFF07C,0): acl1 1, ack2 1, ack3 1
Chip unprotected
writeio(20000100,DDB6): acl1 1, ack2 1
writeio(40100008,20000100): acl1 1, ack2 1
writeio(40100004,8000000A): acl1 1, ack2 1
readio(40100004,A): acl1 1, ack2 1, ack3 1
readio(40100008,F0000012): acl1 1, ack2 1, ack3 1
pollsromstatus()=F0000012 (failed) << according to table 26-2 this indicates the Pump clock frequency is invalid.
Is another step required above in the ** set clock to 48 MHz ** section (above) to select the 48 MHz clock as a source?
Thanks,
Scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No Ideas on this issue?
Thanks,
Scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Scott,
Can you please attach your script so that we can have a look at all parameters?
In the code snippet, I verified the values are correct for WriteIO, but I'm not sure how the second parameter in ReadIO is being used inside the function because the implementation deviates from what we have in the Programmer Spec:
** set clock to 48 MHz **
writeio(40100008,E8B6): acl1 1, ack2 1
writeio(40100004,80000015): acl1 1, ack2 1
readio(40100004,40000015): acl1 1, ack2 1, ack3 1
readio(40100008,A0000000): acl1 1, ack2 1, ack3 1
pollsromstatus()=A0000000 (OK)
Also, you mentioned this: << according to table 26-2 this indicates the Pump clock frequency is invalid.
I do not see in the PSoC4 BLE Programming Specification. I hope you are referring to the same spec.
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dheeraj,
Has there been any progress on this?
Thanks,
Scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Scott,
Please see if this thread helps: errors when programming CYBLE-012011-00 via SWD from external MCU with 001-84858_AN84858
We are currently testing your code to identify the root cause.
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue was due to length of the cable being longer causing delays that affected the SWD timing specifications. Solved by using a shorter cable around an inch long.
Regards,
Dheeraj