[MK10] interrupts during program flash operations

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

[MK10] interrupts during program flash operations

ソリューションへジャンプ
1,393件の閲覧回数
andrewparlane
Contributor IV

I'm using the MK10DX256VLH7 and am looking at erasing and writing program flash.

Section 28.4.9.4 of the TRM has a table of permitted simultaneous flash operations. It indicates that you can not read program flash whilst also writing or erasing from it (obviously different addresses).

Section 28.4.6 states:

The MCU must not read from the flash memory while commands are running (as
evidenced by CCIF=0) on that block. Read data cannot be guaranteed from a flash block
while any command is processing within that block.

What is meant by "block" here? I think this is defined in section 3.5.1.2:

• 1 block of program flash consisting of 2 KB sectors
• 1 block of FlexNVM consisting of 1 KB sectors
• 1 block of FlexRAM

So by if we were talking about program flash, then "that block" would mean "program flash"?

In the KSDK for other kinetis chips (including the 100MHz version of the MK10, that I'm using the drivers from) fsl_flash.c has a small routine that's run out of RAM that starts the flash operation and waits for it to be completed. Which makes sense if you can't read (execute) from program flash during erase/writes to program flash. However there is no code to disable global interrupts, and I can't see anything in the documentation of the API that suggests you should do this.

Obviously an IRQ could be handled if the vector table and the ISR were in RAM, but that's not the case by default.

So I'm just looking for clarification here. Attempting to execute code from any address in program flash during an erase / write to any other address in program flash will result in an error, and therefore interrupts should be disabled around calls to FLASH_Erase() / FLASH_Program() / similar functions, unless the vector table and the ISR code are in RAM.

Thanks,

Andrew

0 件の賞賛
返信
1 解決策
1,388件の閲覧回数
mjbcswitzerland
Specialist V

Hi

Since your device has a single flash block there is no other alternative flash block where programming code can be located so that it can run from there. This means that SRAM is the only place that code can execute from when programming or erasing the Flash.

Any access to Flash during the erase/program period will result in an error and immediate system failure so either interrupt vectors and all code that they could call must be in SRAM or else no interrupt may occur. It is usual to disable interrupts globally during any Flash programming/erasure periods to protect again potential attempts to access it and the associated failure that would result.

If you find reference code not disabling interrupts it will presumably be due to the fact that the entire code is running SRAM or it is simple code that doesn't otherwise use interrupts.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/kinetis/TWR-K60D100M.html

元の投稿で解決策を見る

0 件の賞賛
返信
2 返答(返信)
1,389件の閲覧回数
mjbcswitzerland
Specialist V

Hi

Since your device has a single flash block there is no other alternative flash block where programming code can be located so that it can run from there. This means that SRAM is the only place that code can execute from when programming or erasing the Flash.

Any access to Flash during the erase/program period will result in an error and immediate system failure so either interrupt vectors and all code that they could call must be in SRAM or else no interrupt may occur. It is usual to disable interrupts globally during any Flash programming/erasure periods to protect again potential attempts to access it and the associated failure that would result.

If you find reference code not disabling interrupts it will presumably be due to the fact that the entire code is running SRAM or it is simple code that doesn't otherwise use interrupts.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/kinetis/TWR-K60D100M.html

0 件の賞賛
返信
1,381件の閲覧回数
andrewparlane
Contributor IV

Great, that's as expected, thanks for the confirmation.

0 件の賞賛
返信