PSoC4 confidential

Unofficial PSoC4 manual/FAQ/errata/rumor & wild guess repository.

This document will serve as a repository of undocumented knowledge on the PSoC4 family of chips. I will update it as I learn more things. You really are unlikely to get much use of this without first acquainting yourself with my previous PSoC4 article. Revision history follows:

1. Initial publishing (some TODOs still exist)
2. Register docs added, AV pairs semi-documented (some TODOs still exist)
3. Found how to and added code to show you how to enter non-NMI privileged mode on PSoC4000!
4. Added protected-mode memory map
5. Added SCB investigation in PSoC4000

Table of contents

• Why does it matter?
• Syscalls, their permissions, erorrs, and effects
• I need a unique chip ID
• My SPCIF_GEOMETRY register contents are wrong
• What is this WOUNDING I hear about?
• Undocumented registers?
• What is the boot process?
• What are these AV pairs?
• UART & SPI on PSoC4000 SCB?
• What exactly does "protected" mean?
• How do I dump my SROM?
• I want root!

Why does it matter?

With this info you can use the chip to its full power, write flash in new ways, unlock extra storage, and have a fun time reverse engineering more things. Enjoy :)

Syscalls

Syscall error values

A Unique chip ID exists!

In SFLASH there are a few values that are of interest. A 24-bit Lot ID for the silicon wafer that this chip came from at 0x0FFFF178, The 8-bit wafer number in the lot that this chip came from at 0x0FFFF17B, and the 8-bit X and 8-bit Y coordinates on the wafer that this chip came from (row and colum numbers) at 0x0FFFF17C and 0x0FFFF17D respectively. Clearly in any given family this will be unique as no two chips could occupy the same physical location on the same wafer in the same lot. I am not sure if this is unique inter-family, so you should also, together which these values, use the Silicon ID (16-bit), Revision ID (8-bit), and the family ID (12-bit) values from the SiliconID syscall. Together these form a 24+8+8+8+16+8+12 = 84-bit unique chip ID. Keep in mind that while this will be unique, it is also highly predictable. For example, the 5 PSoC4000 chips I ordered from Mouser only differ in wafer X coordinate, and by exactly one. So you should not use this directly in a place where guessing it correctly would compromise safety. If in doubt, securely hash with salt to obtain a harder-to-guess uniqie ID. A quick-and-dirty function to get the raw unique ID might look like this:

My SPCIF_GEOMETRY register lied to me!

If you read SPCIF_GEOMETRY in some members of the PSoC4 family, you will see it claiming 16K of flash, while the chip only has 8K (as per datasheet, cypress tools, and syscalls). In some members of the PSoC4200M family, you'll see the register claim twice the RAM amount the datasheet says you have. This is not a bug. Well, it kind of is and kind of is not. It is market segmentation at work. The values you see in SPCIF_GEOMETRY are the actual amounts of flash, SFLASH, RAM, and ROM that your chip has. If your datasheet claims less, the remainder is fully functional, but disabled for market segmentation resons. This is done using WOUNDING. With some effort, you can undo this and gain use of extra flash and RAM permanently.

What is WOUNDING?

Wounding is Cypress's method of market segmentation. It turns out that for small sizes of flash and RAM, developing a die with differing amounts and making them costs more than just giving each die the same amount (the larger). But this means you either lower margins or do not sell a low-end product. To avoid both, you can just hide some of the RAM and flash and claim the chip has less. Since using the same die for both is actually cheaper, this allows the company to capture the extra money from people who do want more than the lower amount of flash or RAM.

In PSoC4 chips, this is implemented using WOUNDING registers. These registers are write-once in a stange way. You can always increment them, but you cannot decrement them. Reset clears them. Thus, the higher the value in the WOUNDING register, the more of flash and RAM is hidden and inaccessible. There are, in fact, a few WOUNDING registers. The one for flash and RAM is CPUSS_WOUNDING, which exists at [CPUSS + 0x1C]. In here you'll find a 3-bit bitfield at bits 20..22 for flash limiting, and a 3-bit bitfield at bits 16..18 for RAM limiting. The value (N) you place in those bitfields determines how much ram and flash is left accessible. The formula is easy. Accesible = Total / (2 ^ N). RAM and flash limits may differ. If you try to read this register, you'll find that it is not readable to you. It is a privileged-only register. However, unless you changed it (unlikely as you cannot even read it), the boot process probably set the values for you. How does it know what to? SFLASH! At address 0x0FFFF140 you'll find a word whose contents will be copied to CPUSS_WOUNDING. How is the actual "inaccesibility" implemented? Same way that privileged-only registers are.

It is not only flash and RAM that can get artifically limited. The SAR ADC, in chips that have it, can also be artificially limited. The register for that is SAR_WOUNDING, and it is at [SAR + 0xF04]. privileged-only, of course. I have not seen any SROM code that writes this, but, then again, I have not read SROMs of all the members of the PSoC4 family.

Yes, there are undocumented registers. No you cannot use them [easily].

Like most chips, PSoC4 has many undocumented secret registers. Some fascinating, many mundane. However, unlike most chips, PSoC4's secret registers are not easy to access. Cypress gated access to most using the HPROT[1] flag. The practical upshot of this is that to normal code running on the chip, it looks like these registers do not exist. This is accomplished by repling to the AHB transaction with HRESP[0] = 1 (aka: ERROR). The core understands this as accessing a nonexistent register and triggers a HardFault (or a LOCKUP if at NMI or HardFault priority). I refer to these as privileged-only registers, and the chip is full of them. Every peripheral on the chip has some. Older Cypress docs documented a few of them, like CPUSS_WOUNDING. Newer docs do not mention them at all. Many were never documented at all, for example the insides of the SPCIF module. I will document registers here as I reverse engineer them. Please, however, do keep in mind that these are only my guesses, substantiated only by disassembled SROM code. Any or all of this could be subtly incorrect, incomplete, inaccurate, and/or simply wildly wrong. That being said, I have successfully used most of these as I documented them. The section on privileged execution is a good start on experimenting with these.

What does the boot process do?

Depending on the chip, few activities hapen. I will outline the generic stuff here, and provide specifics as I learn them.

1. Check RAM for a magic value, and if so, assume it contain factory test info and data and execute some code (only later PSoC4 members)
2. Read chip protection value from SFLASH and configure debugger limits (disable access to almost all of the memory space), if in protected mode
3. Configure SWD pins (based on protection level and SFLASH settings)
4. If there is RAM wounding to use, move stack into an area that will be accessible after wounding
5. Apply wounding
6. Checksum SFLASH and verify checksum matches
7. Initialize various registers using AV pairs (that is what SFLASH offsets 0x80-0x140 contain in packed form).
8. Check if debugger has requested a stop (TST_MODE register top bit)
9. Check if SFLASH checksum failed, if so, reset (this will loop forever)
10. Drop privileges (leave privileged mode)
11. If stop was requested, loop in SROM
12. If SFLASH has special boot address dedicated (usually not), jump there
13. If we got this far, boot user code by loading [0x00] -> SP and [0x04] -> PC

AV pair format?

AV pairs (address-value pairs) are values for various hardware registers that are initialized on boot from SFLASH. Since SFLASH contains values that are usually unique per chip and SROM contains others that are always the same, we can assume that all registers written to by AV pair data are different between different chips of the same family.

32-bit AV pairs (0x0FFFF100..0x0FFFF13F) are simple: they literally contain 32-bit address and then 32bit data. Address of 0xffffffff acts as terminator of this list

8-bit AV pairs (0x0FFFF080..0x0FFFF0FF) are complicated and encoded differently on each chip in the family. The only thing they have in common is that they always write 8-bit values to initialize 32-bit registers at 0x4000FF00 or later. Most of them write towards the end of each peripheral's address space (where various calibration registers are). What follows are rough decoders of the 8-bit AV pairs for the old format (4000/4100/4200) and new format 4000S/4100M/4200M. You can tell them apart by looking at the last byte before the zeroes begin. Here 0x37 means old format, 0xff means new. The code is written in this style because it is written to closely match assembly listing and not to be pretty.

PSoC4000 SCB regs look just like other PsoC4 family members. Does that mean it can do UART & SPI too?

I looked into this. It seems like it should. It sort of works. If you clock it, it takes a byte into the shift register even (as per TX_FIFO_STATUS). But that is as far as it goes. I checked the SROM in case there is a register that cripples (WOUNDS?) the SCB, but I found nothing that looks like it. Sorry.

What exactly does "protected" mean?

Protected mode is meant to protect the code in the chip form readout. As you saw in the syscall table, most API are not available in protected mode. Also, most memory is off-limits to the debugger. What is of interest is exactly what memory is and is not accessible. This is not documented and I see no ways to tweak this. I did a full scan (over about a week) of the address space on the PSoC4000S. The accessible areas are CPUSS, TST, and the top level rom table. Here are the values:

How does one dump the SROM?

I've automated this to the exteme in CortexProg (look for it out soon). At this point it is a two-step process. First step automatically finds an exploitable load in the first part of the SROM and uses it to dump said first half. Second step needs an offset of an exploitable gadget in the first half to use to dump the rest. Human intervention is needed once per chip family to find a gadget. This offset is fed to CortexProg to use to dump the rest and enable the "Read As Provileged" function on PSoC to allow access to privileged-only registers for further investigations. What does it look like? Step 1 looks like this.

Step 2 is a bit more work and looks like this

I want root (how to become privileged)

Keep in mind that normally execution in privileged mode is rather limited in a number of ways. To start with, I have not yet found a way to execute in Thread mode as privileged generically on all devices. Currently there needs to be a per-device exploit. The CPU does boot in that way, but I have yet to find a way to do this on demand easily. I did find specific per-family exploits for some devices. See below. For devices without these fancy nice exploits, there is a way to run in NMI-mode privileged mode. What that means is that you're running at NMI priority. What does this cause? Effectively interrupts are disabled while you're running privileged code, since you're executing at a higher priority. But that's not all. You're also at higher priority than HardFault, so if you mess up, the CPU enters LOCKUP state. Your hard fault handler does not run either. And if that is not enough, debugging is also inhibited while in privileged mode, so do not expect your debugger's help. It seems to me that while in privileged mode, the debugger limitations are similar to those that are applied when chip is in protected mode. That means that you can only access very limited things, none of them useful. All of this combined makes execution in privileged mode a rather large pain. But sometimes, it is worth it :).

But there are specific exploits you can use! So, here are the gems you came for. This code will allow you to enter privileged mode on some of the PSoC4 family chips. Not only that, you will not be in NMI mode, so interupts will work and HardFault handlers will work if you mess up! Keep in mind that you still get no debugging! Your debugger (whatever it is) will either freak out or give up as soon as you enter privileged mode. This is by design and cannot be avoided as far as I can tell. This exploit was quite a difficult thing to achieve, but here it is! To enter privileged mode, just call this function. Upon its return you'll be privileged. To exit privileged mode, just write 0 to CPUSS->SYSREQ. This will not work on any other PSoC4 chip family (do not bother trying), and might not even work on other SROM revisions (YMMV). I do not currently have such a simple exploit for other chip families - there I am still stuck doing privileged experimentation in NMI mode. I will try to generalize this exploit as much as I can: to other SROM revisions (if they exist) and other chip families. Stay tuned. Since NMI-mode privileged world is a much harsher world to live in, I will not publish the NMI exploits for those chips until I find one as convenient as this one for those chips. As with all other code here, this is licensed as: free to use for non-commercial use only. No commercial use without my prior approval. Allrighty then, here are the magic bytes: