• State Answer Suggested
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1151 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Boot loader and application stack size problem

David Henry52307
Intellectual 790 points

I am using the Tiva Launchpad and the demo programs in Tivaware.

My bootloader uses the BL_CHECK_UPDATE_FN_HOOK to check for boot condition, which is the presence of a magic number in eeprom. The loading medium is DFU.

My bootloadable application is a mixture of blinyk/boot_demo1 with the addition of pressing SW1, That switch writes the magic number to eeprom then resets the CPU.

The system works fine, I can make different versions of blinky with different colored leds, load them via LM Flash and see the result.

It goes wrong when I increase the stacksize of the blinky application from the 64 words as in the original Tiva source to any number above 70. On pressing SW1 I enter the bootloader but the DFU device does not appear in Device Manager.

By playing with the stack size I can get the DFU to appear in Device Manager but LM Flash can't find it.

I do not understand how the stacksize of the application can have any effect upon the bootloader. Once I reset the CPU, its CPU state from the application is lost, history, no longer relevant.

  • 0
    TI__Guru**** 244380 points
    Hello David,

    Which Tiva device are you using, so that I can recreate the setup.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 790 points
    Sometimes a change you made ages ago and forgot about comes back to bite you in the backside.
    When entering bootloader via a jump to 0x2c (SVC) I have to press the reset button to get to boot loader to run. While not a problem on the Launchpad it is a problem on my custom board that had no reset button, it goes into Hibernate when 'turned off'.
    Accordingly I changed the jump from 0x2c to 0x04 (reset).
    All this worked fine for my simple blinky app which has just 64 words of stack. Then I started working with a real app with a larger stack and the DFU problem appeared.
    Now I've returned to entering bootloader via a jump to 0x2c. That has solved the DFU error problem but now I have to solve the reset problem.
    So I guess this topic thread should be closed. I'll open a new one with the correct question.
  • 0 in reply to David Henry52307
    TI__Guru**** 244380 points
    Hello David,

    The System Vector Reset bit can be used to reset the part once the new image is flashed.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 790 points
    Thats not the issue. I flash using the LM Flasher and check the 'Reset MCU' box. This works fine.
    The ptoblem is getting the bootloader to start.
    After jumping to SVC the bootloader doesn't run until I do a reset. I can tell because my CheckUpdate hook turns on the red led to let me know its arrived. Maybe its caught in a fault trap somewhere.
  • 0 in reply to David Henry52307
    TI__Guru**** 244380 points
    Hello David,

    In fact it would be better to check with the LED if the FaultISR gets invoked and then use the debugger to see where it is faulting at.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 790 points
    Getting closer. By configuring debugger to 'attach to running target' I see that I am stuck in a loop at the beginning of UpdaterUSB where its waiting for something to do.
    As far as I can see the only difference between Reset and SVC in the startup code is that Reset enables FPU just in case its needed, not that I do any FP stuff in either the bootloader or the app. This still doesn't explain whats going on but expect a Eureka moment soon.
  • 0 in reply to David Henry52307
    TI__Guru**** 244380 points
    Hello David

    The boot loader is waiting for an update from USB for an application image. Now that is expected as application code in the first place asked for the boot loader to be invoked

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 790 points
    Hi Amit,
    Mea Culpa. RTFM.
    The USB DFU class assumes that the app calling the bootloader uses a PLL based clock.
    My learning exersize was based upon blinky, which uses the default 32khz crystal as its clock. Enough said.
  • 0 in reply to David Henry52307
    TI__Guru**** 244380 points
    Hello David

    The blinky example does not use the 32K clock but the system clock from the PIOSC, which is not the correct option for USB. The USB requires the system clock be from the PLL which in turn is sourced from the Main Oscillator.

    Regards
    Amit