CYT2B95CAE - Work flash cannot store data and microcontroller's fault is set or resets

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

cross mob
mandar_bhat
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi ,

I am using sample code from TVII_Sample_Driver_Library_7.2.0 library example code of work flash

it is storing some data in workflash and reading data from work flash. ( I want to use this to store some application specific settings data similar to eeprom).

I implemented the sample function in my application and found that fault is generated and my call stack list is lost, as soon as i execute Erase API => (Cy_FlashSectorErase(SectorAddr, CY_FLASH_DRIVER_BLOCKING))

or also may be any other API related to work flash

As my call stack is lost , so after exiting this BasicWorkFlashBlockingTest function, my stack pointer cannot return to the place where this function was invoked, so sytem fault is generated.

I am running this code from M4 code-flash.

Microcontroller's M0+ Core is also initialized.

//***************************************************************************************

// Initialization
Cy_FlashInit(false /*blocking*/);

 

// Test for Small Sector
BasicWorkFlashBlockingTest(TEST_W_SS_ADDR, CY_WORK_SES_SIZE_IN_BYTE);

//***************************************************************************************

// In this routine, whole one sector erased/written/read/verified
void BasicWorkFlashBlockingTest(uint32_t SectorAddr, uint32_t SectorSizeInByte)
{
uint32_t* p_TestFlsTop = (uint32_t*)SectorAddr;

uint32_t SectorSizeInWord = SectorSizeInByte / 4ul;

/** Erasing **/
// Erase
Cy_FlashSectorErase(SectorAddr, CY_FLASH_DRIVER_BLOCKING);

// Verify
Cy_WorkFlashBlankCheck(SectorAddr, CY_FLASH_DRIVER_BLOCKING);

/** Programming **/
for(uint32_t i_addr = SectorAddr, i_addrOffset = 0; i_addr < SectorAddr + SectorSizeInByte; i_addr+=4, i_addrOffset+=4)
{
uint32_t i_dataPos = i_addrOffset % PROGRAM_DATA_SIZE_IN_BYTE;

// Flash
Cy_FlashWriteWork(i_addr, (uint32_t*)&programData[i_dataPos], CY_FLASH_DRIVER_BLOCKING);
}

// Verify
uint32_t* pProgramData = (uint32_t*)programData;
for(uint32_t i_wordId = 0; i_wordId < SectorSizeInWord; i_wordId++)
{
uint32_t i_dataPos = i_wordId % PROGRAM_DATA_SIZE_IN_WORD;
CY_ASSERT(p_TestFlsTop[i_wordId] == pProgramData[i_dataPos]);
}

/** Erasing Again **/
// Erase
/*Cy_FlashSectorErase(SectorAddr, CY_FLASH_DRIVER_BLOCKING); */

// Verify
/*Cy_WorkFlashBlankCheck(SectorAddr, CY_FLASH_DRIVER_BLOCKING); */
}

 

Please suggest any ideas to make it work.

Thanks in Advance.

 

 

 

0 Likes
1 Solution
yanf
Moderator
Moderator
Moderator
50 replies posted 50 sign-ins 25 solutions authored

Hi Mandar,

 

If I understand you correctly, you are using your own board design and a MCU from Infineon, right?

That will make some difference but for this particular instance, I think they are still the same if you use internal flash, which is implemented in MCU. 

I would suggest you use the address in SDL demo project first to do the test. Because there are some addresses that are forbidden to write on (or even read). Please refer to the TRM, Chapter 4.3.

And you should also change the project configuration profile (on the left upper in IAR) to rev_c according to your MCU.

Screenshot (27).png

 Then, the linker file should have been changed to " $PROJ_DIR$\..\..\linker_directives_tviibe.icf " now. You can double check it. 

Have a try if these settings bring it back to work.

Best Regards,

Finn

View solution in original post

0 Likes
10 Replies
yanf
Moderator
Moderator
Moderator
50 replies posted 50 sign-ins 25 solutions authored

Hi mandar_bhat,

Can you double check your configuration is selected correctly according to your evaluation board. 

It seems no problems with these codes you have provided when I test it on my board. 

Kind Regards,

Finn

0 Likes

Hi Finn,

      I donot have an evaluation board with me.

I am using an project hardware, wherein i am testing this workflash feature.

Already in this board features like uart, adc, timer, i2c and other things are working according to my application.

I am running M0+ core at 80-mhz and M4 core at 160-mhz.

My microntroller chip revision is : rev_c  (CY_MCU_rev_c)

Please can you suggest which all configuration settings i should check. I am using IAR workbench for development.

I see that, if i try to access any work flash related api, my controller hangs 

Thanks and Regards,

Mandar Bhat

0 Likes
yanf
Moderator
Moderator
Moderator
50 replies posted 50 sign-ins 25 solutions authored

Hi Mandar,

 

If I understand you correctly, you are using your own board design and a MCU from Infineon, right?

That will make some difference but for this particular instance, I think they are still the same if you use internal flash, which is implemented in MCU. 

I would suggest you use the address in SDL demo project first to do the test. Because there are some addresses that are forbidden to write on (or even read). Please refer to the TRM, Chapter 4.3.

And you should also change the project configuration profile (on the left upper in IAR) to rev_c according to your MCU.

Screenshot (27).png

 Then, the linker file should have been changed to " $PROJ_DIR$\..\..\linker_directives_tviibe.icf " now. You can double check it. 

Have a try if these settings bring it back to work.

Best Regards,

Finn

0 Likes
mandar_bhat
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi Finn,

 I modified my board configuration to using 8-MHz internal main oscillator (IMO), that is achived by calling SystemInit();  API, as mentioned in all the demo project. Actually main clock should operate at 80 MHZ  for M4, but it opeartes at 50 MHZ not sure why this happens.

But after operating CPU at 50 MHZ, writing to  work-flash memory is working and also reading from work-flash memory is also working.

 

But actually i want to operate M4 core at faster speed, say at 160 Mhz , so i have acheived this by using sample code  ==> Cypress\TVII_Sample_Driver_Library_7.2.0\tviibe2m\src\examples\sysclk\DifferentCPUClock\main_cm0plus.c

We have connected 8 MHz crystal/resonator in the board and acheiving 160 MHZ clock for M4 and 80MHZ for M0+ core, by using configuration of External crystal oscillator (ECO)

so now here with higher clock speed  for M4, writing to work-flash and reading from work-flash is not working.

In datasheet and reference manual, it is not mentioned  what should be the CPU clock rate for work-flash to work properly.

I want to know why work-flash is not working at higher speed and how we can make it work.

 

Thanks and Regards,

Mandar Bhat

 

 

0 Likes
yanf
Moderator
Moderator
Moderator
50 replies posted 50 sign-ins 25 solutions authored

Hi mandar_bhat,

Q:"Actually main clock should operate at 80 MHZ  for M4, but it opeartes at 50 MHZ not sure why this happens."

A:

For the MCU you are using, the CYT2B95, it should run at 160MHz for its M4F CPU, not 80MHz. Some demo boards has a ECO on it which is 16MHz, so it sets PLL for 10x to get 160MHz clock for cpus. If you use 8MHz internal oscillator, you should set the multiplier to 20x.  

As for the actual clock frequency, as far as I know, this MCU does not provide test pin for inspecting core clocks.  Can you elaborate your method of measuring core frequency, how do you know that the CPU running at 50MHz?

 

Q:"so now here with higher clock speed  for M4, writing to work-flash and reading from work-flash is not working"

A: I have no problems writing to work-flash when M4 is configured and "claiming" its running at 160MHz. Let me double check it after you elaborating the method to test its actual clock rate.

 

Best Regards,

Finn

 

0 Likes

Hi yanf,

Regarding M4 working at 50 MHz  while using my board configuration to using 8-MHz internal main oscillator (IMO), that is achived by calling SystemInit();  API, as mentioned in all the demo project. 

This 50 Mhz value is available while debugging inside SystemInit() function step by step

 

/*******************************************************************************
* Function Name: Cy_SysClk_GetFllOutputFrequency
****************************************************************************//**
*
* Reports clock FLL output frequency. This function does not measure the frequency,
* just return values which is the result of calculation from register values
* and values set by Cy_SysClk_InitGetFreqParams.
*
* \param result A pointer to variable in which the frequency value is stored.
*
* \return \cy_en_sysclk_status_t
*
* Note: Please call this function after setting base clock information
* by calling Cy_SysClk_InitGetFreqParams
*******************************************************************************/
cy_en_sysclk_status_t Cy_SysClk_GetFllOutputFrequency(uint32_t *result)
{
uint32_t fllInputFreq;
cy_en_sysclk_status_t status;
status = Cy_SysClk_GetFllInputFrequency(&fllInputFreq);
if(status != CY_SYSCLK_SUCCESS)
{
*result = 0ul;
return(status);
}

cy_stc_fll_manual_config_t fllConfig;
Cy_SysClk_FllGetConfiguration(&fllConfig);

#if (CY_USE_PSVP == 1)
*result = fllInputFreq;
return(CY_SYSCLK_SUCCESS);
#else
if(fllConfig.outputMode == CY_SYSCLK_FLLPLL_OUTPUT_INPUT)
{
*result = fllInputFreq;
return(CY_SYSCLK_SUCCESS);
}

if(SRSS->unCLK_FLL_CONFIG.stcField.u1FLL_ENABLE == 0ul)
{
*result = fllInputFreq;
return(CY_SYSCLK_SUCCESS);
}

bool locked = Cy_SysClk_FllGetLockStatus();
if(locked == false)
{
*result = 0ul;
return(CY_SYSCLK_INVALID_STATE); // unknown state
}

*result = (fllInputFreq * fllConfig.fllMult) / fllConfig.refDiv / (fllConfig.enableOutputDiv + 1ul);
return(CY_SYSCLK_SUCCESS);
#endif
}

 

(fllInputFreq     8000000 (8MHZ)  
fllConfig.fllMult     400 0x190
fllConfig.refDiv      32 0x20
fllConfig.enableOutputDiv     1 0x01

 

(8Mhz * 400) / 32 / 2 = 50 Mhz

0 Likes
yanf
Moderator
Moderator
Moderator
50 replies posted 50 sign-ins 25 solutions authored

Hi mandar_bhat,

Following my last reply, I'm sorry to say that I forgot EXT_CLK pin can be used as an output of internal CLK_HF. So there actually is a test pin for internal clock when correspondingly configuring multiplexer. 

I have tested the evaluation board CYTVII-B-E-176-so using the demo project in SDL 7.2. When the CLK_HF is configured at 160MHz, it actually running at 1/6.2ns*1000 = 161MHz, which is quite accurate considering my observation error. So the MCU have an accurate clock speed at what it claims. Meanwhile, the flash read/write procedure is working as expected

tek00000.png

 

Kind Regards,

Finn

0 Likes

Now at present the issue of read/write of workflash at 160 MHz is resolved

 

Analysis of the issue

As  i mentioned earlier, actually i wanted to operate M4 core at faster speed, say at 160 Mhz , so i have acheived this by using sample code  ==> Cypress\TVII_Sample_Driver_Library_7.2.0\tviibe2m\src\examples\sysclk\DifferentCPUClock\main_cm0plus.c

We have connected 8 MHz crystal/resonator in the board and acheiving 160 MHZ clock for M4 and 80MHZ for M0+ core, by using configuration of External crystal oscillator (ECO)

In the sample code and also in my code for M0, we are configuring the clock and doing systick_init as given below

/***** Cy_SysTick_Init ******/
{
    Cy_SysTick_Init(CY_SYSTICK_CLOCK_SOURCE_CLK_CPU, 160000ul);
    Cy_SysTick_SetCallback(0ul, ToggleGpio);
}

 

void ToggleGpio(void)
{
/*
static int a = 0;
a++;
if(a> 10000)
{
   a = 0;
}
*/
}

Fix for the issue

commenting out the below 2 lines code  of systick, makes the read and write to workflash issue resolved.

Cy_SysTick_Init(CY_SYSTICK_CLOCK_SOURCE_CLK_CPU, 160000ul);
Cy_SysTick_SetCallback(0ul, ToggleGpio);

 

Actually interrupts like CPUIntIdx0_IRQn and CPUIntIdx1_IRQn is resrved for M0+ use.

Not sure whether systick_init  uses  CPUIntIdx0_IRQn and CPUIntIdx1_IRQn and what is the cause of the issue?

please find the clock configuration code of M0+ in attachment

0 Likes
yanf
Moderator
Moderator
Moderator
50 replies posted 50 sign-ins 25 solutions authored

Hi mandar_bhat,

I can not run your code properly. In the line 229 of your code, you assign CLKPATH1 to HFCLK0. But you have never configured CLKPATH1, no signal on it. The system then halted. I don't think it is correct. Can you check if this is your expected behaviour?

For your question, "interrupts like CPUIntIdx0_IRQn and CPUIntIdx1_IRQn is resrved for M0+ use".

I don't think so. Nor any document indicates that. There is an ADC demo project in SDL7.2 called "OneChannelConversion_SwTrigger", I changed its line 175 from CPUIntIdx3_IRQn to CPUIntIdx0_IRQn. Then put the code to M4 core. It turned out that no problem occured.

So I am wondering how you draw the conclusion that "CPUIntIdx0_IRQn and CPUIntIdx1_IRQn is resrved for M0+".

In addition, I recommend you to use the systeminit() in SDL if possible.

Best Regards,

Finn

0 Likes
kobot
Level 1
Level 1
First reply posted First question asked First like given

I also found the problem of acquaintance, and found that the work-flash data has been changing. So I used j-flash to erase the entire flash,including code flash and work flash. But when I checked the data of 14000000-1403ffff with the dap emulator, I found that there was still data, and it was being updated all the time.So I can’t use this area too.

0 Likes