Anonymous
Not applicable
Feb 17, 2017
02:56 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 17, 2017
02:56 AM
So, where is the errata sheet for PSoC4000? I've searched the site high and low, and found nothing. Despite that, I already found some actual bugs:
- Documentation for the SROM syscall to setup clocks is wrong (TRM "Document No. 001-89309 Rev. *C" page 144). Docs say that this syscall takes a pointer to memory, and there I write param. This never works. Passing the actual param directly (like for "checksum" system call) in SYSARG register does work.
- Either documentation for SPCIF_GEOMETRY is wrong, or the chip has a bug where it reports the wrong value. My CY8C4013SXI-400 (which has 8K of flash) reports this register's value as 0x0001003f. As per register doc sheet (Document No. 001-90002 Rev. *C) that means it has (0x3f + 1) * 256 = 16384 bytes of flash. Of course in reality the chip has 8 (and as a test, I do indeed get a fault if I read past 8K)
- If I use the "Load Flash Bytes" SROM syscall shortly after boot, and point it to an area of flash where i put in the proper params to load 64 bytes of data into the write latches (0x0000d7b6, 0x0000003f) but I DO NOT WRITE THE NEXT 16 WORDS (let's assume i am ok writing whatever garbage was there into flash) , SROM locks up (actual cortex-m0 core lockup bit set and all). However, if those same words of RAM have ever been written before since boot (by core or by the MEMAP) no lockup occurs. (Yes, flash clock is properly set up. Yes, literally writing zeroes or any other values to these bytes immediately before or long before the syscall makes it work properly/)
Given all this, I am guessing at least a few more issues exist. is there a list?
Labels
5 Replies
Feb 17, 2017
07:11 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 17, 2017
07:11 AM
Why do you use the SysCalls directly, and don't use the provided components? They work around such issues, and are fixed regularly with new Creator releases.
I have never seen an errata, but you can ask Cypress directly by creating a support case (top right corner, 'MyCases').
Feb 17, 2017
09:45 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 17, 2017
09:45 AM
Because it is documented and because I can? Because I have my own tools, including debuggers and need ways to program the chip? Because I'm curious? :). (Also does creator even run on Linux? :). Thanks for the pointer. I'll log a case.
Mar 07, 2017
06:05 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 07, 2017
06:05 AM
In 2014 I found documentation on undocumented CSD/IDAC registers (no info on the TRM, only half the registers where documented) in the components' source code. Don't know if the TRM has meanwhile been updated.
Mar 07, 2017
09:58 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 07, 2017
09:58 AM
Yeah the docs aren't wonderful. Ezi2c for example isn't documented at all in terms of how to make it work 🙂
Mar 14, 2017
02:31 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 14, 2017
02:31 PM
I eared you enjoy tough challenges 🙂