SCB1 Register Address Map Missing in Documents

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

cross mob
BrTe_297846
Level 1
Level 1

I'm fairly new to the PSoC architecture so I expect some frustration learing a new part. I've programmed PIC, Intel, Zilog, and Motorola microcontrollers in the past and they all have their learning curves and documentation issues. This is not a slam in any way as I'm just pointing out something that created some confusion to me when learning this device.

   

I'm working on a program that uses the SCB UART funtionality on a CY8CKIT-049-42xx board. so I was poking around trying to learn the register locations. I see on page 23 of the PSoC 4 Architecture TRM (Rev C 3/25/2014) that there are two SCBs. When I look at page 50 I see that the SCB registers are mapped to addresses 0x40060000-0x4006FFFF. I then go to the PSoC 4 Registers TRM (Rev A 6/25/2013) to actually look at the individual register definitions and I see the registers mapped in that address space, but there is no indication of two SCBs. So I compile a simple program in PSoC Creator and I hunted around in the include files and find that in the cydevice_trm.h file the SCB1 register address map appears to be 0x40070000-0x4007FFFF. This range is not even defined in the PSoC 4 Architecture TRM.

   

While I'm OK with finding this information out in a rather reverse engineering way, it would be a lot clearer if the documentation was updated to reflect the full picture especially with regards to registers in the device. I would rather not have to rely on compiled code to understand the register mappings. If I missed some errata document out there my apologies, and I would appreciate a link to it for my documentation collection.

   

I do like the PSoC devices though and look forward to using these devices in future projects.

0 Likes
10 Replies
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Consider filing a CASE and supply a link to your post.

   

Hopefully that should bring attention to the TRM update

   

needed.

   

 

   

    

   

          

   

To create a technical or issue case at Cypress -

   

 

   

www.cypress.com

   

“Support”

   

“Technical Support”

   

“Create a Case”

   

 

   

You have to be registered on Cypress web site first.

   

 

   

Regards, Dana.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Welcome in the fascinating world of PSoCs!

   

That is a major difference between PICs and PSoCs with Creator: You do not have to care for register addresses.

   

When you build a project that uses components (as nearly every project has got) some C-language files are generated with the APIs and the internal handling which you may open to look at the way Cypress's engineers handle that. Moreover a process named "Fitter" could decide from time-to-time to use different hardware resources for optimization purposes which changes the involved registers and the associated files generated.

   

Especially when you are new to PSoCs: Start "Thinking PSoC". You may solve problems in hardware, in software or in a combination of both. How much hardware and how much software is up to you and is an individual decision. Even "Generating" new hardware using HDL is possible, when you like.

   

 

   

Bob

0 Likes
BrTe_297846
Level 1
Level 1

Thanks for the pointer Dana, I opened a case with Cypress Technical Support just now.

   

 

   

Yes Bob it is a new world being introduced to an old world engineer .

   

 

   

I cut my teeth on the Intel 8048 microcontroller many years ago - a different world back then for sure (and no I don't want to go back to those days.) I am somewhat getting and embracing the concept, but my brain is wired to understand what is really going on under the covers. I'm sure there is coming a day when I need to fit 10 pounds of programming poo into a 1 pound PSoC box and clever techniques will have to be utilized that require a somewhat intimate knowledge of the architecture to make it happen. At least that is what has happened to me in the past. I do like what I see so far, but trust has to be earned and I'm not at that level yet.

   

 

   

Best regards,

   

 

   

BT

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

The actual state of the component collection from Cypress is rather trustworthy. When you follow the history at end of the datasheet you can see that there haven't been essential changes lately. Except the brandnew BLE which needed an update recently, the complete framework looks rather stable.

   

I admit: there is a lot to learn about PSoCs, but the kits come in handy and you find an example for nearly every component. Datasheets for the components are just a mouseclick away and all are structured similarly, easy to find what you are searching for.

   

8048? I think we both are of matchable age, although I started on an IBM360/370 😉

   

 

   

Bob

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

When you really really want to use registers (in rare cases the needed functionality is not exposed by the component API) then use the provided DEFINEs for the registers instead of the absolute address. As Bob said, PSoC Creator might change the resource assignment (e.g. due to what the external pins are).

   

But its even better to use the provided components, since they provide a higher level API (and are just much easier to use).

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

I think for SCB1 the address is correct, When you have a project with SCB0 used, you will see that it indeed starts at 0x40060000 (or just check cydevice_trm.h, that has all peripherals).

   

That should be described a little bit better - the register TRM only shows the set of registers for the first component if there are multiple, and the other follow with a certain offset. When you need them, the cydevice_trm.h has the base addresses for all instances (and their number might differ by the actual chip used).

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

If you want to use register addresses, or pointers to them, the

   

HW mapped registers are safe to use, as their addresses do

   

not change.

   

 

   

 

   

Register adressing can be useful in configuration updates and

   

saves that span several registers, especially if addressing sequential

   

as you know. Results in tight simple code.

   

 

   

As pointed out earlier the register defines are safest to use.

   

 

   

Regards, Dana.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

I didn#t want to imply that the register addresses can change (although they can when switching e.g. between the different PSoC4 families). But what can change is the resource assignment. E.g. when using a TCPWM which one exactly is assigned for you might change in subsequent runs, and then your registers are the wrong ones. Thats why you should always use the DEFINEs generated by Creator.

0 Likes
BrTe_297846
Level 1
Level 1

Thanks all for the interesting discussion. While it is nice to know register locations for direct access at times I definitelty understand the importance of using the #defines whenever possible. Even though the #define names are fairly straight forward I still find myself working backwards though the include files from the register address to identify what #define is the one I should be using, and that again requires a good document that lists all of the register mappings for the part.

   

 

   

BT

0 Likes
Anonymous
Not applicable

There are 2 SCB blocks in PSoC 4. SCB0's registers are mapped to 0x40060000-0x4006FFFF and SCB1's registers are mapped to 0x40070000-0x4007FFFF.

   

But the PSOC 4 register TRM has information about the SCB registers at 0x40060000 - Page-337
http://www.cypress.com/?docID=44837

   

But it doesnot specifically mention about SCB0 or SCB1.

   

Also, in the cydevicetrm.h, you can see the following defines,
CYDEV_SCB0_BASE 0x40060000u
CYDEV_SCB1_BASE 0x40070000u

   

But I will ensure that I report this to the respective team to correct this.

   

Thanks,
Keerthi

0 Likes