Problem with SafeRoutineCaller while overwriting flash.

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Problem with SafeRoutineCaller while overwriting flash.

881 次查看
sufyanalamad1
Contributor I

Hello,

My setup is a Cortex-M0+ (MKL15Z128VFT4) running freeRTOS.

I am trying to write to flash using the ProcessorExpert components. Inside of of method IntFlashLdd2_Main, SafeRoutineCaller() is used. This function has been confirmed to be the point of failure. The processor resets to __vect__table 0x00.

Our bootloader does not use freeRTOS, and also writes to flash, but works perfectly. This leads me to think that the issue arises from the freeRTOS ports taskENTER_CRITICAL() and taskEXIT_CRITICAL().

However our generated watchdog clearing function also uses the above freeRTOS functions, and that is working fine.

I would appreciate some help resolving this issue.

Thanks.

0 项奖励
回复
4 回复数

790 次查看
danielchen
NXP TechSupport
NXP TechSupport

Hi sufyanalamad

I would suggest you increase the stack size of the flash task to 1000 or bigger to see whether it helps.

Regards

Daniel

0 项奖励
回复

790 次查看
sufyanalamad1
Contributor I

Hello Daniel, thanks for responding.

I created a separate task just for the flashing, it has 2100 bytes of stack allocated to it. I am unable to allocate more due to what I think is heap fragmentation, as I am deleting some tasks before creating this one.

Anyways, 2100 sounds like it should be enough -- yet it still fails in the same way. For the flashing, I am doing 16 bytes at a time, exactly like our bootloader.

Do you still think it's a stack problem?

Thanks.

EDIT: I have just managed to try it with 8192 bytes allocated to the flashing task. Still the same problem.

0 项奖励
回复

790 次查看
danielchen
NXP TechSupport
NXP TechSupport

Hi sufyanalamad

From your description, it is not a stack problem.  could you share your project for further analyzing?

Regards

Daniel

0 项奖励
回复

790 次查看
sufyanalamad1
Contributor I

Hey Daniel,

Really sorry but I'm not at liberty to be sharing the project!

If I attempt flashing before freeRTOS is started, it seems to work. This seemingly confirms my suspicion that the flashing is mainly failing due to the freeRTOS port of taskENTER_CRITICAL() and taskEXIT_CRITICAL().

However for production, it's not feasible that we actually do this. For this reason, I would still like to solve the problem of performing flashing within the freeRTOS context.

Thanks.

0 项奖励
回复