<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Strange behaviour of Safe Routine for writting flash in Digital Signal Controllers</title>
    <link>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1406961#M2392</link>
    <description>&lt;P&gt;No chance of testing the "bug" (or my missinterpretation) in&amp;nbsp;&lt;SPAN&gt;IFsh1_SetWordFlash?&lt;/SPAN&gt;&lt;/P&gt;</description>
    <pubDate>Mon, 31 Jan 2022 08:12:29 GMT</pubDate>
    <dc:creator>cabl</dc:creator>
    <dc:date>2022-01-31T08:12:29Z</dc:date>
    <item>
      <title>Strange behaviour of Safe Routine for writting flash</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1389924#M2357</link>
      <description>&lt;P&gt;Hi everybody,&lt;/P&gt;&lt;P&gt;I´m using a 56F82646 part and having some trouble with the PE´s IntFlash component. To my understanding there´s something odd in the PE code for the SafeRoutineCaller:&lt;/P&gt;&lt;P&gt;- when stack location where&amp;nbsp;SaveRoutineStackSpace is placed is under 0x7FF (RAM address), SafeRoutineInDataPtr gets a value under 0xFFF (double of SaveRoutineStackSpace address), and&amp;nbsp;SafeRoutineInCodePtr=0xF000 +&amp;nbsp;SafeRoutineInDataPtr is a valid address under 0xFFFF and everything works fine. At least this es what I can see in the debugger.&lt;/P&gt;&lt;P&gt;- when stack&amp;nbsp;location where&amp;nbsp;SaveRoutineStackSpace is placed is over 0x7FF, SafeRoutineInDataPtr gets a value over 0xFFF and&amp;nbsp;SafeRoutineInCodePtr=0xF000 +&amp;nbsp;SafeRoutineInDataPtr is a INVALID address (over 0xFFFF). Now it does not work.&lt;/P&gt;&lt;P&gt;If I force&amp;nbsp;SaveRoutineStackSpace to be global and be placed at low RAM addresses it always work fine, without any other change in the code, just the&amp;nbsp;SaveRoutineStackSpace position.&lt;/P&gt;&lt;P&gt;This behaviour seems to be independent of the memory model and width of the pointer used in the project options.&lt;/P&gt;&lt;P&gt;Am I not understanding something here?&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks in advance.&lt;/P&gt;</description>
      <pubDate>Tue, 21 Dec 2021 07:32:03 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1389924#M2357</guid>
      <dc:creator>cabl</dc:creator>
      <dc:date>2021-12-21T07:32:03Z</dc:date>
    </item>
    <item>
      <title>Re: Strange behaviour of Safe Routine for writting flash</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1391052#M2360</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;As the following screenshot in MCU_DSC_Compiler.pdf, if you use byte access in the application code and in small model, the address must be less than 0x7FFF.&lt;/P&gt;
&lt;P&gt;The MCU_DSC_Compiler.pdf is located&lt;/P&gt;
&lt;P&gt;......\Freescale\CW MCU v11.1\MCU\Help\PDF&lt;/P&gt;
&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="xiangjun_rong_0-1640229513184.png" style="width: 400px;"&gt;&lt;img src="https://community.nxp.com/t5/image/serverpage/image-id/166031i7F9B0C1D038130D6/image-size/medium?v=v2&amp;amp;px=400" role="button" title="xiangjun_rong_0-1640229513184.png" alt="xiangjun_rong_0-1640229513184.png" /&gt;&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;Hope it can help you&lt;/P&gt;
&lt;P&gt;BR&lt;/P&gt;
&lt;P&gt;XiangJun Rong&lt;/P&gt;</description>
      <pubDate>Thu, 23 Dec 2021 03:20:49 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1391052#M2360</guid>
      <dc:creator>xiangjun_rong</dc:creator>
      <dc:date>2021-12-23T03:20:49Z</dc:date>
    </item>
    <item>
      <title>Re: Strange behaviour of Safe Routine for writting flash</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1391129#M2361</link>
      <description>&lt;P&gt;Thanks for the response! I did know that. But the problem is I can´t see any warning or protection in the PE IntFlash component code that protects against invalid address when there is high stack usage. How should this code be modified to force word access?&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;</description>
      <pubDate>Thu, 23 Dec 2021 06:24:35 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1391129#M2361</guid>
      <dc:creator>cabl</dc:creator>
      <dc:date>2021-12-23T06:24:35Z</dc:date>
    </item>
    <item>
      <title>Re: Strange behaviour of Safe Routine for writting flash</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1391264#M2362</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;Pls try to use large data model rather than small data model to avoid the issue.&lt;/P&gt;
&lt;P&gt;BR&lt;/P&gt;
&lt;P&gt;XiangJun Rong&lt;/P&gt;</description>
      <pubDate>Thu, 23 Dec 2021 09:20:29 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1391264#M2362</guid>
      <dc:creator>xiangjun_rong</dc:creator>
      <dc:date>2021-12-23T09:20:29Z</dc:date>
    </item>
    <item>
      <title>Re: Strange behaviour of Safe Routine for writting flash</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1392123#M2368</link>
      <description>&lt;P&gt;No luck, sorry. The large memory model still fails when executing SafeRoutineCaller if stack usage is high.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 27 Dec 2021 07:03:51 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1392123#M2368</guid>
      <dc:creator>cabl</dc:creator>
      <dc:date>2021-12-27T07:03:51Z</dc:date>
    </item>
    <item>
      <title>Re: Strange behaviour of Safe Routine for writting flash</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1392567#M2369</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;I have reviewed your code, but I do not see the code to erase flash, if you program flash space which are not erased, you may damage the flash.&lt;/P&gt;
&lt;P&gt;How about using the code:&lt;/P&gt;
&lt;P&gt;/*!&lt;BR /&gt;** @file main.c&lt;BR /&gt;** @version 01.16&lt;BR /&gt;** @brief&lt;BR /&gt;** Main module.&lt;BR /&gt;** This module contains user's application code.&lt;BR /&gt;*/ &lt;BR /&gt;/*!&lt;BR /&gt;** @addtogroup main_module main module documentation&lt;BR /&gt;** @{&lt;BR /&gt;*/ &lt;BR /&gt;/* MODULE main */&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;/* Including needed modules to compile this module/procedure */&lt;BR /&gt;#include "Cpu.h"&lt;BR /&gt;#include "Events.h"&lt;BR /&gt;#include "Pins1.h"&lt;BR /&gt;#include "IFsh1.h"&lt;BR /&gt;#include "IntFlashLdd1.h"&lt;BR /&gt;/* Including shared modules, which are used for whole project */&lt;BR /&gt;#include "PE_Types.h"&lt;BR /&gt;#include "PE_Error.h"&lt;BR /&gt;#include "PE_Const.h"&lt;BR /&gt;#include "IO_Map.h"&lt;BR /&gt;#include "Init_Config.h"&lt;BR /&gt;#include "PDD_Includes.h"&lt;/P&gt;
&lt;P&gt;#define PROADDRESS 0x7000&lt;/P&gt;
&lt;P&gt;unsigned int array[1024];&lt;BR /&gt;unsigned int temp,i;&lt;BR /&gt;unsigned int *pointer;&lt;/P&gt;
&lt;P&gt;void main(void)&lt;BR /&gt;{&lt;BR /&gt;/* Write your local variable definition here */&lt;/P&gt;
&lt;P&gt;/*** Processor Expert internal initialization. DON'T REMOVE THIS CODE!!! ***/&lt;BR /&gt;PE_low_level_init();&lt;BR /&gt;/*** End of Processor Expert internal initialization. ***/&lt;/P&gt;
&lt;P&gt;/* Write your code here */&lt;BR /&gt;/* Write your code here */&lt;BR /&gt;for(i=0;i&amp;lt;1024;i++)&lt;BR /&gt;{&lt;BR /&gt;array[i]=i;&lt;BR /&gt;}&lt;BR /&gt;pointer=(unsigned int *)PROADDRESS;&lt;BR /&gt;//erase program flash from address:0x1 F000&lt;BR /&gt;IFsh1_EraseSector((unsigned long)PROADDRESS);&lt;BR /&gt;pointer=(unsigned int *)PROADDRESS;&lt;BR /&gt;asm(nop);&lt;BR /&gt;for(i=0; i&amp;lt;1024; i++)&lt;BR /&gt;{&lt;BR /&gt;IFsh1_SetWordFlash((unsigned long)pointer,array[i]);&lt;BR /&gt;pointer++;&lt;BR /&gt;}&lt;BR /&gt;for(;;) {}&lt;BR /&gt;}&lt;/P&gt;
&lt;P&gt;/* END main */&lt;BR /&gt;/*!&lt;BR /&gt;** @}&lt;BR /&gt;*/&lt;BR /&gt;/*&lt;BR /&gt;** ###################################################################&lt;BR /&gt;**&lt;BR /&gt;** This file was created by Processor Expert 10.3 [05.09]&lt;BR /&gt;** for the Freescale 56800 series of microcontrollers.&lt;BR /&gt;**&lt;BR /&gt;** ###################################################################&lt;BR /&gt;*/&lt;/P&gt;
&lt;P&gt;BR&lt;/P&gt;
&lt;P&gt;XiangJun Rong&lt;/P&gt;</description>
      <pubDate>Tue, 28 Dec 2021 07:56:19 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1392567#M2369</guid>
      <dc:creator>xiangjun_rong</dc:creator>
      <dc:date>2021-12-28T07:56:19Z</dc:date>
    </item>
    <item>
      <title>Re: Strange behaviour of Safe Routine for writting flash</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1393717#M2370</link>
      <description>&lt;P&gt;Hi!&lt;/P&gt;&lt;P&gt;The erasure of the sector is done automatically by the PE component if needed, no problem with this (option safe write with erase).&lt;/P&gt;&lt;P&gt;Have you been able to test&amp;nbsp;&lt;SPAN&gt;IFsh1_SetWordFlash function when stack usage is high?&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Regards,&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 03 Jan 2022 09:43:57 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1393717#M2370</guid>
      <dc:creator>cabl</dc:creator>
      <dc:date>2022-01-03T09:43:57Z</dc:date>
    </item>
    <item>
      <title>Re: Strange behaviour of Safe Routine for writting flash</title>
      <link>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1406961#M2392</link>
      <description>&lt;P&gt;No chance of testing the "bug" (or my missinterpretation) in&amp;nbsp;&lt;SPAN&gt;IFsh1_SetWordFlash?&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 31 Jan 2022 08:12:29 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Digital-Signal-Controllers/Strange-behaviour-of-Safe-Routine-for-writting-flash/m-p/1406961#M2392</guid>
      <dc:creator>cabl</dc:creator>
      <dc:date>2022-01-31T08:12:29Z</dc:date>
    </item>
  </channel>
</rss>

