Announcements

Help us improve the Power & Sensing Selection Guide. Share feedback

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

cross mob
lock attach
Attachments are accessible only for community members.
user_3716231
Level 4
Level 4
25 sign-ins 10 sign-ins 5 sign-ins

What are these memories(marked red) used for in cyfitter_cfg.c? And how to decide their size?

static const cfg_memset_t CYCODE cfg_memset_list[] = {
/* address, size */
{(void CYFAR *)(CYREG_PRT0_DR), 16u},
{(void CYFAR *)(CYREG_PRT3_DR), 64u},
{(void CYFAR *)(CYREG_PRT15_DR), 16u},
{(void CYFAR *)(CYDEV_UCFG_B0_P0_U0_BASE), 4096u},
{(void CYFAR *)(CYDEV_UCFG_B1_P2_U0_BASE), 2048u},
{(void CYFAR *)(CYDEV_UCFG_DSI0_BASE), 2560u},
{(void CYFAR *)(CYDEV_UCFG_DSI12_BASE), 512u},
{(void CYFAR *)(CYREG_BCTL0_MDCLK_EN), 32u},
};

 

I even cannot find defnition of below memories(marked red) in the datasheet.

CYCONFIGCPY((void CYFAR *)(CYREG_PRT12_DR), (const void CYFAR *)(BS_IOPINS0_7_VAL), 10u);
CYCONFIGCPY((void CYFAR *)(CYREG_PRT1_DM0), (const void CYFAR *)(BS_IOPINS0_1_VAL), 8u);
CYCONFIGCPY((void CYFAR *)(CYREG_PRT2_DM0), (const void CYFAR *)(BS_IOPINS0_2_VAL), 8u);

0 Likes
1 Solution
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

@user_3716231 ,

cfg_memset_list is used by cyfitter_cfg() in the PSoC initialization routine to clear these memory areas.

The sizes of each of these memory areas are not up to you.  These sizes are determined by the PSoC chip you are using.

BS_IOPINS0_7_VAL, BS_IOPINS0_1_VAL and BS_IOPINS0_2_VAL are not in the datasheet.  These addresses are pointing to data in the PSoC 'ROM' area designed to be read from not written to.  These values pre-load the CYREG_PRT12_DR, CYREG_PRT1_DM0 and CYREG_PRT2_DM0 registers respectively.

These factors in your question should be left as-is. 

Is there a reason you need to know about these factors?

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

0 Likes
6 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

@user_3716231 ,

cfg_memset_list is used by cyfitter_cfg() in the PSoC initialization routine to clear these memory areas.

The sizes of each of these memory areas are not up to you.  These sizes are determined by the PSoC chip you are using.

BS_IOPINS0_7_VAL, BS_IOPINS0_1_VAL and BS_IOPINS0_2_VAL are not in the datasheet.  These addresses are pointing to data in the PSoC 'ROM' area designed to be read from not written to.  These values pre-load the CYREG_PRT12_DR, CYREG_PRT1_DM0 and CYREG_PRT2_DM0 registers respectively.

These factors in your question should be left as-is. 

Is there a reason you need to know about these factors?

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
lock attach
Attachments are accessible only for community members.

The sizes of each of these memory areas are not up to you.  These sizes are determined by the PSoC chip you are using.

Where does datasheet mention their size? I cannot find it.

 

BS_IOPINS0_7_VAL, BS_IOPINS0_1_VAL and BS_IOPINS0_2_VAL are not in the datasheet.  These addresses are pointing to data in the PSoC 'ROM' area designed to be read from not written to.  These values pre-load the CYREG_PRT12_DR, CYREG_PRT1_DM0 and CYREG_PRT2_DM0 registers respectively.

These factors in your question should be left as-is. 


So how to decide the value in BS_IOPINS0_7_VAL address? It is different with this project.


Is there a reason you need to know about these factors?


I want to program the firmware by myself and do not want to rely on the existing code.(just for practicing)

0 Likes

@user_3716231 ,

All the code you referenced is in the PSoC_initialization function that gets implemented immediately after reset.   This initialization is used to make sure that certain SRAM memory and registers used by the PSoC internal services get set to values that should prevent unwanted operations at reset.

Right after PSoC_initialization, the memory and registers used as defined in your TopDesign get set.  These include GPIO pins, UDB blocks and other fixed function resources.

Then after all this is done, it enters main() to execute your application code.   In your application, you can then change these memory and registers as you need them.   (Having said that, it is still recommended to use System or Component API function calls to modify these elements.  It is safer to use the API calls since Infineon provides them because sometimes there are multiple registers to be set and there might be an order to the setting.  The API calls should have that knowledge embedded.)

Suggestion:  Start your experience by using one or more of the examples given.  It appears you are already using the "SPI_Master" example.   These are very good examples of proper PSoC code generation.   You will see that usually only System or Component API calls are made to the internal resources being used.   Again, this is the 'safe' way.

Is there a specific goal you are trying to achieve that needs you to directly control specific internal PSoC resources?

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

I mean I want to program the code by myself and I do not use psoc creator IDE. I will use vscode to program the code without any GUI componets and compile it with make command to generate hex file and upload to my psoc board. That's what I want.

0 Likes

I am afraid that you  are heading in wrong direction. The Creator GUI is what makes PSoC a ...PSoC. Without the GUI it is practically useless. You may practice some other chips which have no extended periphery network.   

@user_3716231 ,

You are definitely allowed to create your own PSoC initialization functions and to create your own component logic (HW state machines = HSM) from scratch without the Creator IDE.

However odissey1 and I can tell this would not be a trivial matter.   We both have created numerous user-designed TopDesign schematics and components.   That's what I've enjoyed and appreciated about the PSoC5.   I'm assuming odissey1 would say the same.   

However, I doubt if either of us would abandon the Creator IDE.  Cypress created this tool and its various sub-tools to make it easier and more intuitive to design.  The TopDesign sub-tool is a excellent means of self-documentation of the HSM you can create.  Note: The IDE and it's sub-tools took many people over many years to create and perfect.  I very highly respect that.

If you don't what to use TopDesign to start your design, you don't have to create a schematic.  To create your own HSM and internal routing, you can write and read directly from the peripheral registers from your application code.   I can guarantee this method will make your work multitudes more difficult for no other reason than you having to understand how to set the peripheral registers correctly and in order.

If you want to stick with the PSoC-family of parts where you can self-program all the HSM available, you can use PSoC6s which don't have UDB blocks.  Also the ModusToolBox IDE has access to PDL (Peripheral Device Library), and HAL (HW abstraction Layer) API calls to control the peripherals from your code.

In summary, odissey1 and I are advanced users of the PSoC5.  We highly appreciate all the work the Cypress engineers put into the part's flexible architecture.   As advanced users, we have created our own components which is not common for PSoC5 users to do.  To do this, we definitely rely on all the hard work Cypress SW developers put into the PSoC Creator IDE.   Without it, we would have given up years ago.

Len
"Engineering is an Art. The Art of Compromise."