TMS320F2800157: Setting OTP bootpin and bootmode

Hello John,

John Treubig said:

From below (5.8 & 5.7) and above (5.4.3.2) it would appear that I need to write 0xFF32 to address 0x78008 (Z1-GPREG1), 0x5AFF to address 0x78009 (Z1-GPREG1), and 0xFF37 to address 0x7800C (Z1-GPREG3)

As per your requirements:

• Write 0x5AFFFF20 to 0x78008 to configure GPIO32 (32 = 0x20) as BMSP0 and disable BMSP1.
  • GPIO numbers are encoded in hex, so you have to convert from decimal
• Write 0xFFFF0307 to 0x7800C to configure BOOTDEF0=I2C boot option 0 and BOOTDEF1=Flash boot option 0
  • Each BOOTDEF# entry has 8-bit width

For programming these configurations, please refer to 5.5 Writing Values in the OTP Using the Flash API Plugin in this user's guide. You can use the Flash API plugin to program the respective OTP locations with your boot configurations. This user's guide is also very useful for understanding the C2000 boot flow. 

You can also use the DCSM tool in SysConfig to graphically configure the boot configurations: https://www.ti.com/lit/an/spracp8a/spracp8a.pdf

To generate a hex file, please refer to Chapter 12 in the C28x Assembly Language Tools Guide for output format options: https://www.ti.com/lit/ug/spru513/spru513.pdf. The Hex utility is built into CCS (Project Properties > Build > Tools > C2000 Hex Utility). 

Best,

Matt

Hi Matt,

Your explanation seems complete, and I will try it as soon as possible.  I got sucked into a line down situation and will have to support it first.

Will leave the thread open until I verify and ask any additional clarifying questions then.

John

Hello,

Sounds good, please don't hesitate to ask any questions on this thread.

Best,

Matt

Just keeping the thread alive as I'm still handling the line down.  Thanks.

Hi John,

No worries, I'm still here if you have any questions.

Best,

Matt

Just extending my reply time as I was made aware these items close after 30 days.  Looks like I will be getting back on this in a week.

Hi John,

That's right, threads close after 30 days automatically. I usually check in before then to confirm resolution. 

Best,

Matt

Hi Matt,

Worked through the Z1-GPREG1 & Z1-GPREG3 settings and agree with what was presented.

Here's my issue - I would like to configure these two OTP registers during manufacturing but don't see a solution to support setting just these registers. 

Looked at the DCSM tool in SysConfig, but that employs a program and seems to set additional registers beyond these two - see below.

To explain the current system that is planned for production:

• Z1-GPREG1 & Z1-GPREG3 settings: Finding no means to create a Hex file for just these registers and application to load the hex file.
• Bootloader contained in I2C: I have a CCS development that will output using HEX2000 to hex file for my vendor to load the I2C PROM.
• Application contained in TMS320 FLASH:  Vendor can load via XDS110 USB Debug Probe or pre-program the IC.

I've looked at UniFlash and here's what I'm seeing that I need your confirmation. 

• Load the application to TMS320 FLASH using the Program Tab -> Select Load Image -> Load Image -> Verify image
• Z1-GPREG1 & Z1-GPREG3 set using the Settings and Utility Tab -> GPREG(BOOTCTRL) and set as shown below
  Z1-GPREG1 (0x78008)(32 bits) 0x 5AFFFF20

  Z1-GPREG2 (0x7800A)(32 bits) 0x FFFFFFFF

  Z1-GPREG3 (0x7800C)(32 bits) 0x 0xFFFF0307

  Z1-GPREG4 (0x7800E)(32 bits) 0x FFFFFFFF

  -> Program

If this is workable, there appears to be some automation support too.   Once we confirm the capability exists, I can investigate it further.

Let me know what you think and thanks for the help,

John

Hello,

John Treubig said:

Looked at the DCSM tool in SysConfig, but that employs a program and seems to set additional registers beyond these two - see below

You can use the DCSM tool output as a template and remove the additional registers from being programmed in DCSM.asm (comment out or delete). I will note that most of the registers are being set to their default value (except for the BMSPs and BOOTDEFs). You can confirm this by inspecting the memory locations in the memory browser.

John Treubig said:

If this is workable, there appears to be some automation support too.   Once we confirm the capability exists, I can investigate it further.

Yes, this should be feasible. Uniflash has automation support, please refer to the following resources:

1. https://software-dl.ti.com/ccs/esd/uniflash/docs/latest_qsguide.html#command-line-interface
2.  TMS320F28P550SJ: Uniflash CLI unlocking and programming 
   1. Note: Thread is for programming CSMPSWD, but can be applied to GPREG1/3
      1. Z1GPREGProgram is what you need to call as an argument for an action to take place
         1. The action button names can be found in the TMS320F280015x_FlashProperties.xml in CCS (ccs_base > DebugServer > propertyDB folder)
      2. You would have to set the Z1PGREG value, ex: -b Z1GPREGProgram -s Z1GPREG1=0xFFFFFFFF 

Best,

Matt

HI Matt,

Trying to use UniFlash with F2800157 LaunchPad.  The LaunchPad can be discovered and a connection started.  Since I'm attempting to learn how to use UniFlash and didn't want to write anything, I attempt to read memory and get two errors:

Error!
Cannot read properties of undefined (reading 'addListener')

Texas Instruments XDS110 USB Debug Probe/IcePick_C_0
Error connecting to the target: (Error -2131 @ 0x0) Unable to access device register. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.3.0.3656)

I found the following link for the 039 LaunchPad with the similar error but didn't see any fix: LAUNCHXL-F280039C

I downloaded the ccxml file from the session but didn't see anything I could modify to fix the problem.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="configuration_0">
        <instance XML_version="1.2" desc="Texas Instruments XDS110 USB Debug Probe" href="connections/TIXDS110_Connection.xml" id="Texas Instruments XDS110 USB Debug Probe" xml="TIXDS110_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe">
                   <instance XML_version="1.2" href="drivers/tixds510ajsm.xml" id="drivers" xml="tixds510ajsm.xml" xmlpath="drivers"/>
                   <instance XML_version="1.2" href="drivers/tixds510c28x.xml" id="drivers" xml="tixds510c28x.xml" xmlpath="drivers"/>
                   <instance XML_version="1.2" href="drivers/tixds510cs_child.xml" id="drivers" xml="tixds510cs_child.xml" xmlpath="drivers"/>
                   <instance XML_version="1.2" href="drivers/tixds510icepick_c.xml" id="drivers" xml="tixds510icepick_c.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="TMS320F2800157" href="devices/f2800157.xml" id="TMS320F2800157" xml="f2800157.xml" xmlpath="devices"/>
            </platform>
        </connection>
    </configuration>
</configurations>

Hope you can suggest a solution.

John

Hello John,

Can you try modifying your ccxml to the following (see line 10)? It looks like you're using 4-pin JTAG as opposed to 2-pin JTAG (cJTAG) -- the LaunchPad requires cJTAG. I believe this is a mistake in UniFlash and look into having this fixed.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
    <configuration XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe_0">
        <instance XML_version="1.2" desc="Texas Instruments XDS110 USB Debug Probe_0" href="connections/TIXDS110_Connection.xml" id="Texas Instruments XDS110 USB Debug Probe_0" xml="TIXDS110_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe_0">
            <instance XML_version="1.2" href="drivers/tixds510icepick_c.xml" id="drivers" xml="tixds510icepick_c.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds510c28x.xml" id="drivers" xml="tixds510c28x.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds510cs_child.xml" id="drivers" xml="tixds510cs_child.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds510ajsm.xml" id="drivers" xml="tixds510ajsm.xml" xmlpath="drivers"/>
            <property Type="choicelist" Value="4" id="SWD Mode Settings"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="TMS320F2800157_0" href="devices/f2800157.xml" id="TMS320F2800157_0" xml="f2800157.xml" xmlpath="devices"/>
            </platform>
        </connection>
    </configuration>
</configurations>

Best,

Matt

Hi Matt,

Got UniFlash to see the memory on the LauchPad, so all that remains is setting the OTP.  Will do that once I get my custom bootloader code working.

Here's the next struggle that I need help with: I have my application loaded in Flash at 0x80000 on the LauchPad.  I've created a bootloader that will be resident in an I2C EEPROM.  Since the bootloader loads to RAM, I'm attempting to start it up on the F2800157 LaunchPad and have it jump to 0x80000 (application) so I can prove out the full boot process.

I've checked the application map file and BEGIN is at 00080000.  When I run the bootloader In RAM in debug and execute the jump at the end of the bootloader, it sets the PC to args_main.c.obj and the appears to hang in _c_int00.  Is there a way that I can set the debugger to allow it to execute the application, even though I won't be able to debug through it?

Thanks in advance,

John 

Hi Matt,

Did a little more research.  Here's the syntax I'm using that doesn't work.  I've verified in the debugger JumpAddr contains 0x80000:

Hello,

That group of code looks correct. Did ACC get loaded with the correct return value (0x80000)?

How are you branching to the application? Did you verify that the application code was programmed correctly by the bootloader (via Run > Load > Verify Program)?

Best,

Matt

Hi Matt,

The application has been verified by booting directly to flash and all the functionality is there.  Thus, if I don't load the bootloader to RAM I am able to run the application directly.

I load the Bootloader to RAM and single stepped the debugger through the code below and ACC has 0x80000 in it after return(JumpAddr) is executed.

   // Test BootFlag status

    if(BFlag == 0x01)

    {

        GPIO_writePin(LED_BUSY, 0); //GpioDataRegs.GPASET.bit.GPIO30 = 1; // LED on

        AppReload();

        JumpAddr = ADR_BOOT_RAM;            // Mode boot: API+ALGO en RAM

    }

    else

    {

      GPIO_writePin(LED_BUSY, 1); //GpioDataRegs.GPACLEAR.bit.GPIO30 = 1; // LED off

      JumpAddr = FLASH_ENTRY_POINT;    // Jump to Flash: Application

    }

     return (JumpAddr);

I just noticed I have an issue in my reload path (jump to RAM), but I will fix that as we still need to get the jump to flash fixed.

Thanks,

John

Hi Matt,

I just brute forced it to jump to flash using asm("    LB 0x8000");  Wondering why the return doesn't work.

John

Hi John,

What may be going on is that the codestartbranch.asm is not handling the address returned from main() of the bootloader. Please try using the codestartbranch.asm used by the F280015x flash kernel, which handles this in the ExitBoot routine.

;//###########################################################################
;//
;// FILE:   flash_kernel_ex3_codestartbranch.asm
;//
;// TITLE: Branch for redirecting code execution after boot.
;//
;// For these examples, code_start is the first code that is executed after
;// exiting the boot ROM code.
;//
;// The codestart section in the linker cmd file is used to physically place
;// this code at the correct memory location. This section should be placed
;// at the location the BOOT ROM will re-direct the code to. For example,
;// for boot to FLASH this code will be located at 0x80000.
;//
;// In addition, the example f280013x projects are setup such that the codegen
;// entry point is also set to the codestart label. This is done by linker
;// option -e in the project build options. When the debugger loads the code,
;// it will automatically set the PC to the "entry point" address indicated by
;// the -e linker option. In this case the debugger is simply assigning the PC,
;// it is not the same as a full reset of the device.
;//
;// The compiler may warn that the entry point for the project is other then
;//  _c_init00. _c_init00 is the C environment setup and is run before
;// main() is entered. The codestart code will re-direct the execution
;// to _c_init00 and thus there is no worry and this warning can be ignored.
;//
;//###########################################################################
;//
;//
;// $Copyright:
;// Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/
;//
;// Redistribution and use in source and binary forms, with or without 
;// modification, are permitted provided that the following conditions 
;// are met:
;// 
;//   Redistributions of source code must retain the above copyright 
;//   notice, this list of conditions and the following disclaimer.
;// 
;//   Redistributions in binary form must reproduce the above copyright
;//   notice, this list of conditions and the following disclaimer in the 
;//   documentation and/or other materials provided with the   
;//   distribution.
;// 
;//   Neither the name of Texas Instruments Incorporated nor the names of
;//   its contributors may be used to endorse or promote products derived
;//   from this software without specific prior written permission.
;// 
;// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
;// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
;// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
;// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
;// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
;// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
;// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
;// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
;// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
;// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
;// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
;// $
;//###########################################################################

***********************************************************************

WD_DISABLE  .set  1    ;set to 1 to disable WD, else set to 0

    .ref _c_int00
    .ref main
    .global code_start
    .global ExitBoot

***********************************************************************
* Function: codestart section
*
* Description: Branch to code starting point
***********************************************************************

    .sect "codestart"
    .retain

code_start:
    .if WD_DISABLE == 1
        LB wd_disable       ;Branch to watchdog disable code
    .else
        LB _c_int00         ;Branch to start of boot._asm in RTS library
    .endif

;end codestart section

***********************************************************************
* Function: wd_disable
*
* Description: Disables the watchdog timer
***********************************************************************
    .if WD_DISABLE == 1

    .text
wd_disable:
    SETC OBJMODE        ;Set OBJMODE for 28x object code
    EALLOW              ;Enable EALLOW protected register access
    MOVZ DP, #7029h>>6  ;Set data page for WDCR register
    MOV @7029h, #0068h  ;Set WDDIS bit in WDCR to disable WD
    EDIS                ;Disable EALLOW protected register access
    LB _c_int00         ;Branch to start of boot._asm in RTS library
    ;LCR main

 ; Cleanup and exit.  At this point the EntryAddr
; is located in the ACC register
    LB  ExitBoot
    .endif

;end wd_disable

;-----------------------------------------------
; ExitBoot
;-----------------------------------------------
;-----------------------------------------------
;This module cleans up after the boot loader
;
; 1) Make sure the stack is deallocated.
;    SP = 0x400 after exiting the boot
;    loader
; 2) Push 0 onto the stack so RPC will be
;    0 after using LRETR to jump to the
;    entry point
; 2) Load RPC with the entry point
; 3) Clear all XARn registers
; 4) Clear ACC, P and XT registers
; 5) LRETR - this will also clear the RPC
;    register since 0 was on the stack
;-----------------------------------------------

ExitBoot:

__stack:    .usect ".stack",0

;-----------------------------------------------
;   Insure that the stack is deallocated
;-----------------------------------------------

    MOV SP,#__stack

;-----------------------------------------------
; Clear the bottom of the stack.  This will endup
; in RPC when we are finished
;-----------------------------------------------

    MOV  *SP++,#0
    MOV  *SP++,#0

;-----------------------------------------------
; Load RPC with the entry point as determined
; by the boot mode.  This address will be returned
; in the ACC register.
;-----------------------------------------------

    PUSH ACC
    POP  RPC

;-----------------------------------------------
; Put registers back in their reset state.
;
; Clear all the XARn, ACC, XT, and P and DP
; registers
;
; NOTE: Leave the device in C28x operating mode
;       (OBJMODE = 1, AMODE = 0)
;-----------------------------------------------
    ZAPA
    MOVL  XT,ACC
    MOVZ  AR0,AL
    MOVZ  AR1,AL
    MOVZ  AR2,AL
    MOVZ  AR3,AL
    MOVZ  AR4,AL
    MOVZ  AR5,AL
    MOVZ  AR6,AL
    MOVZ  AR7,AL
    MOVW  DP, #0

;------------------------------------------------
;   Restore ST0 and ST1.  Note OBJMODE is
;   the only bit not restored to its reset state.
;   OBJMODE is left set for C28x object operating
;   mode.
;
;  ST0 = 0x0000     ST1 = 0x0A0B
;  15:10 OVC = 0    15:13      ARP = 0
;   9: 7  PM = 0       12       XF = 0
;      6   V = 0       11  M0M1MAP = 1
;      5   N = 0       10  reserved
;      4   Z = 0        9  OBJMODE = 1
;      3   C = 0        8    AMODE = 0
;      2  TC = 0        7 IDLESTAT = 0
;      1 OVM = 0        6   EALLOW = 0
;      0 SXM = 0        5     LOOP = 0
;                       4      SPA = 0
;                       3     VMAP = 1
;                       2    PAGE0 = 0
;                       1     DBGM = 1
;                       0     INTM = 1
;-----------------------------------------------

    MOV  *SP++,#0
    MOV  *SP++,#0x0A0B
    POP  ST1
    POP  ST0

;------------------------------------------------
;   Jump to the EntryAddr as defined by the
;   boot mode selected and continue execution
;-----------------------------------------------

    LRETR

;eof ----------

	.end


;//
;// End of file.
;//

Best,

Matt

Hi Matt,

Here's the copy of F280015x codestartbranch.asm that I'm running.  I even cut and pasted your copy in and that didn't change how things executed, as it still returns to args_main.c then to boot28.asm.

;//###########################################################################
;//
;// FILE:   f280015x_codestartbranch.asm
;//
;// TITLE: Branch for redirecting code execution after boot.
;//
;// For these examples, code_start is the first code that is executed after
;// exiting the boot ROM code.
;//
;// The codestart section in the linker cmd file is used to physically place
;// this code at the correct memory location. This section should be placed
;// at the location the BOOT ROM will re-direct the code to. For example,
;// for boot to FLASH this code will be located at 0x80000.
;//
;// In addition, the example f280015x projects are setup such that the codegen
;// entry point is also set to the codestart label. This is done by linker
;// option -e in the project build options. When the debugger loads the code,
;// it will automatically set the PC to the "entry point" address indicated by
;// the -e linker option. In this case the debugger is simply assigning the PC,
;// it is not the same as a full reset of the device.
;//
;// The compiler may warn that the entry point for the project is other then
;//  _c_init00. _c_init00 is the C environment setup and is run before
;// main() is entered. The codestart code will re-direct the execution
;// to _c_init00 and thus there is no worry and this warning can be ignored.
;//
;//###########################################################################
;//
;//
;// $Copyright:
;// Copyright (C) 2024 Texas Instruments Incorporated - http://www.ti.com/
;//
;// Redistribution and use in source and binary forms, with or without 
;// modification, are permitted provided that the following conditions 
;// are met:
;// 
;//   Redistributions of source code must retain the above copyright 
;//   notice, this list of conditions and the following disclaimer.
;// 
;//   Redistributions in binary form must reproduce the above copyright
;//   notice, this list of conditions and the following disclaimer in the 
;//   documentation and/or other materials provided with the   
;//   distribution.
;// 
;//   Neither the name of Texas Instruments Incorporated nor the names of
;//   its contributors may be used to endorse or promote products derived
;//   from this software without specific prior written permission.
;// 
;// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
;// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
;// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
;// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
;// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
;// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
;// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
;// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
;// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
;// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
;// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
;// $
;//###########################################################################

***********************************************************************

WD_DISABLE  .set  1    ;set to 1 to disable WD, else set to 0

    .ref _c_int00
    .global code_start

***********************************************************************
* Function: codestart section
*
* Description: Branch to code starting point
***********************************************************************

    .sect "codestart"
    .retain

code_start:
    .if WD_DISABLE == 1
        LB wd_disable       ;Branch to watchdog disable code
    .else
        LB _c_int00         ;Branch to start of boot._asm in RTS library
    .endif

;end codestart section

***********************************************************************
* Function: wd_disable
*
* Description: Disables the watchdog timer
***********************************************************************
    .if WD_DISABLE == 1

    .text
wd_disable:
    SETC OBJMODE        ;Set OBJMODE for 28x object code
    EALLOW              ;Enable EALLOW protected register access
    MOVZ DP, #7029h>>6  ;Set data page for WDCR register
    MOV @7029h, #0068h  ;Set WDDIS bit in WDCR to disable WD
    EDIS                ;Disable EALLOW protected register access
    LB _c_int00         ;Branch to start of boot._asm in RTS library

    .endif

;end wd_disable

    .end

;//
;// End of file.
;//

I think I see the issue.  I'm debugging this by running this directly from RAM and not using a boot pin to vector me into the bootloader.  So when I do use my code as a bootloader, the return with the location of flash should work?  

Meanwhile, it looks like I should use the asm("    LB 0x8000"); to check my code out before I use the boot pin.

Is there any issue with leaving the asm("    LB 0x8000"); in when using the bootpin?

Thanks in advance,

John

Hi John,

That is odd. I just tried it on my setup (with CCS debug mode and not from reset) and was able to perform the return to 0x80000 successfully. Could you try emulating a boot to RAM and see if that is the issue?

John Treubig said:

Is there any issue with leaving the asm("    LB 0x8000"); in when using the bootpin?

I'm assuming you mean 0x80000 here. There shouldn't be any issues using the LB instruction, we use this method in our LFU example implementations.

Best,

Matt

Hi Matt,

I agree about the oddity as I'm using CCS 20.3.0.14 and CPU1_RAM to boot to RAM.  For the sake of simplicity, I hard coded return(0x80000); and after executing the 0x80000 is loaded in XAR4 (viewing the registers) but never gets transferred to the PC.  Below is what the disassembly shows, but I'm not understanding what it means.  

	0x008FEB	8F080000    MOVL         XAR4, #0x080000
	0x008FED	FE84        SUBB         SP, #4
	0x008FEE	A8A9        MOVL         @ACC, XAR4
	0x008FEF	0006        LRETR   

Not sure where else to look to find out why my return isn't to 0x80000.

John

Hello John,

LRETR performs a long return using the return PC (RPC). The MOVL stores 0x80000 into the ACC. Can you verify that the contents of the ACC is moved into the RPC afterwards? This should be done in your codestartbranch.asm, as seen in the ExitBoot routine above.

Also, are you using any compiler optimizations?

Best,

Matt