• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 16 subscribers
  • Views 134 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.

SIMPLELINK-LOWPOWER-SDK: ResetISR vs resetISR vs no override

Fred P
Expert 2120 points
Part Number: SIMPLELINK-LOWPOWER-SDK
Other Parts Discussed in Thread: CC2340R5, SYSCONFIG, CC2340R2

Tool/software:

I migrate my code from CC2340R2 Development Platform (R2 RGE Package) to CC2340R5 Development Platform (R5 RKP package) using Sysconfig.

It does not build anymore.

I notice the CC23x0r5.cmd (not linking) is different from CC23x0r2.cmd (builds correctly) on this line:

/* Override default entry point.                                             */
--entry_point ResetISR

I can get the program linked by renaming to resetISR (notice the lowercase r).  The my code appears to run fine.  It may be only driving high one pin, but it does wonderfully.

I don't know if the R2 build works as I don't have the board to test it.  At first, I selecvted this board by mistake.

If anyone knows, why would one board override the program entry point and not the other?  To my understanding, the two boards and devices are very similar.  Therefore, I am not expecting a different startup scheme.

Anyhow, overriding entry point should not be related to hardware...

What's right and what's not?

Note: Using Simplelink lowpower SDK 8.10 and CCS v12.8

  • 0
    TI__Mastermind 32340 points

    Hi,

    Did you make sure to follow this note in the migration process? https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_8_10_01_02/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/porting-guides/cc2340r5_to_cc2340r21.html

    The note says:

    ```

    If a new linker command file is generated after migration (named cc23x0r2.cmd in the project files) please make sure to exclude it from build (or eliminated it from the project files) so that the original lpf3_app_freertos.cmd file is used during build time.

    ```

    This same note should also apply when migrating from CC2340R2 to CC2340R5 (except the file name for this process would now be cc23x0r5.cmd).

    For more background, in the SDK there are 2 versions of the "startup":

    1. C:\ti\<F3 SDK ver>\kernel\freertos\startup\startup_cc23x0r5_ticlang.c
    2. C:\ti\<F3 SDK ver>\source\ti\devices\cc23x0r2\startup_files\startup_ticlang.c

    By default, the FreeRTOS SDK examples pull in version 1, which names it resetIsr.

    BUT, the migration step assumes startup version 2... hence the extra note in the migration guide.

    Thanks,
    Toby

  • 0 in reply to Toby
    Expert 2120 points

    I would not  have guessed it applies to me, especially since that I'm not using FreeRTOS at all.

    The file you refer in #2 does hold a ResetISR() function.  Same file for R5 as well.  Since the linker complains, that file is likely not part of the build.

    But file in #1 holds a resetISR() and since it builds ok when I modify the function name in the .cmd, it must be that this file is part of the build.

    But I am not using FreeRTOS.  Why is it building in FreeRTOS stuff?

    Something's weird no?

    I am building a NoRTOS project from scratch so to understand how things work.  Clearly discovering a lot!

    Thanks again!

  • +1 in reply to Fred P
    TI__Mastermind 32340 points
    Fred P said:

    But file in #1 holds a resetISR() and since it builds ok when I modify the function name in the .cmd, it must be that this file is part of the build.

    But I am not using FreeRTOS.  Why is it building in FreeRTOS stuff?

    There is also a nortos version of #1 here: C:\ti\<F3 SDK ver>\kernel\nortos\startup\startup_cc23x0r5_ticlang.c

    That one also contains resetISR.

    My guess is that the *rtos versions of startup are pulled in (resetIsr), while the SysConfig is assuming the rtos-agnostic startup (ResetIsr).

    You do bring up a good point though, perhaps the documentation should be updated like so:

    Current version Candidate revised version
    If a new linker command file is generated after migration (named cc23x0r2.cmd in the project files) please make sure to exclude it from build (or eliminated it from the project files) so that the original lpf3_app_freertos.cmd file is used during build time. In general, if a new linker command file is generated after migration (named cc23x0r*.cmd in the project files) please make sure to exclude it from build (or eliminated it from the project files) so that the project's original lpf3*.cmd file is used during build time.

    Do you think this revised version would've been more clear?

    I believe this was a temporary note anyways, and should be removed once there are new versions of SysConfig and SDK which handle the linker file (*.cmd) more correctly.

  • 0 in reply to Toby
    Expert 2120 points

    ok, Sysconfig isrtos-agnostic and thus, calls for ResetISR().

    Then it means that nortos is considered an RTOS (it has a resetISR just as FreeRTOS does).  Good to know.

    Also, I bet that the resetISR I build is actually the one from nortos, not FreeRTOS'.

    This is clearer now.

    Still, Sysconfig calls for nortos files in its generated genlibs file but indicates ResetISR() in "its" .cmd file.

    This is a bug, correct?  The would be what the note is about?   Your modification proposal, I feel its an improvment but I don't know what "lpf3" refers to... 

    As for the --entry_point line commented out in cc23x0r2.cmd, I wonder where it comes from.  I deleted the fle, did the migration again and the one created now is identical to cc23x0r5.cmd (but for memory stuff).

    I created a new blank project for an R2 but the line is not commented out either.

    For sure I did not commented out this line by accident!  It stood out to me at first sight!

    That one might stay unanswered...