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.

[BLE-CC254x-1.4.0] (SimpleBLEPeriphera) Sample Project Project CC2540 can not run on (smartRF05+EM2540) with define (HAL_LCD=FALSE)

Other Parts Discussed in Thread: CC2541

Very strange issue.

BLE stack 1.4.0. Using smartRF05+EM2540 as target board. When using the original Sample project "SimpleBLEPeriphera", if with define (HAL_LCD=TRUE), everything is fine. But if set the (HAL_LCD=FALSE), it can not run, when do the debugging, it will keep looping between "HAL_BOARD_INIT();" and "osal_init_system();".

Found this issue at my modified project, at first I though I did something wrong. Then I tried the original code as above with no modification, also has this issue. I'm confused. Is this an know issue? Anyone has any clue? Thanks.

  • Hello,

    I just tried this out CC2540EM, LCD=FALSE, SmartRF05, and it is working. Not sure what may be happening in your case. Maybe see if you can drill down into osal init to see where it gets stuck.

    BR,

    -Greg

  • Hi Greg,

    Thanks for your reply. Appreciate your help, I finally figured out that it is because I'm using IAR 8.30.2 after days and hours of troubleshooting and debugging with no luck and had to post on forum to ask for help.

    After I installed IAR 8.20.2 and tried using this old version IDE, everything works well for both the SimpleBLEPeriphera project and my own project...

    Hope my experience will help if someone encounter similar issue in the future.

    Regards,

    Yuming

  • I'm seeing this behaviour I think, did anyone find out whether 8.30.2 can be used? Its a pain to get a different IAR license

  • I'm one of the first people to claim IAR is trash, but I don't think version 8.30.2 is to blame.

    I am using 8.30.2 and the simpleBLEPreipheral works fine for me with HAL_LCD FALSE and TRUE. Hal_init() doesn't do much other than change some IO settings. It sounds like something is massively wrong if the program counter jumps back in time. 

    Are you using a fresh install of the 1.4 stack?

    Can you use the "rebuild all" option instead of just recompiling files you recently edited?

    Are you erasing the flash before debugging?

    Are you using custom hardware?

    I don't think its smart to say 8.30 is to blame. This is covering up a problem with a rumor workaround instead of deducing and addressing the real issue.

  • I checked out IAR 8.20.2

    It requires going back to BLE-CC254x-1_3_2

    The issue doesn't occur. HAL_LCD can be set FALSE and the board works

  • Has anyone found the solution to this issue?  I am having the same problem with the SimpleBLEPeripheral project for CC2541 on custom PCB.

    It will advertise fine when HAL_LCD=TRUE, but does not advertise at all when HAL_LCD=FALSE.

    I am using stack BLE-CC254x-1.4.0 with IAR 8.30.2

  • Hi Fulano de Tal and Tim,

    Got email notification for the thread update, and good to know that some other people got similar/same problem. Hopefully this thread can be helpful and save your time.

    Here is the infomation again: For Quick Way Out. Using BLE-CC254x-1.4.0 with IAR 8.20.2. Do not use BLE-CC254x-1.4.0 with IAR 8.30.2.

    My experience is that: At that time I was using IAR 8.30.2 and when I tried to compile BLE-CC254x-1.4.0, I got some linker errors. And after some searching and research I did some modification to the linker script etc. And it works. Seems to be happy story until I got this strange behavior as stated in my main thread. At first I was suspecting I did some thing wrong since I have made a lot of modifications. After spending my time troubleshooting, I found that the original code has exactly same behavior. So finally I found that when using BLE-CC254x-1.4.0 with IAR 8.20.2, everything works well by default. And with IAR8.30.2, it is not. So quick way out: use IAR 8.20.2.

    Don't get me wrong. I'm not saying that IAR 8.30.2 can not be used. It just that there's some compatibility issues need to be resolved in order to make it working. I will say it should be able to be done if it is not 100% guarantee. I was busy and with the worry that even this was resolved and some other issues may pop up since IAR 8.30.2 was not officially supported by TI regarding CC254x-1.4.0. So I didn't dig further, if anyone found the root cause, hopefully we can get the change to know and for sure it will benefit us all.

    Is is unfair to just blame TI or IAR for issues popping up. IAR keeping upgrading and introducing new things/features/improvements for their product, which is what I like most and at the same time hate a lot. There's huge compatibility issues for IAR compiler, can you imagine the pain of keeping 4 versions of IAR 8051 workbench at the same development PC? And that is just for 8051, we got ARM workbench also... and AVR if even more unlucky... It makes me sick... For TI, each stack release they tie to a specific IAR IDE version, and newer IAR version is not supported/working! At first you may be excited and play with it to get newer IDE working for example, and it is truly enjoyable, you may discover some new things you never touched before. Well, sometimes after all of these suffering, easy way out: install and use corresponding version that matches with your project if it can be done.

    Regards,

    Yuming

  • Hi Peter,

    Can you share with us what you did to make the 8.30.2 fully working with BLE-CC254x-1.4.0?

    I know that BLE-CC254x-1.4.0 works well with 8.20.2. And when I use 8.30.2, I did some modifications to get rid of some compiling errors. Suspect these modifications are not perfect. Appreciate if you can share with us how you made 8.30.2 fully working with BLE-CC254x-1.4.0. Thanks and all the best wishes.

    Regards,

    Yuming

  • I am experiencing the same issue. I also discovered that turning all optimizations with HAL_LCD=FALSE works but that's no solution.
  • I finally found a work-around: Set the number of Virtual Registers to 28 (or greater) in the project config.

    There is a line in the Module Map that says "VIRTUAL REGISTERS" which appears to be automatically determined during compiler optimization. When HAL_LCD=TRUE, VIRTUAL_REGISTERS=18. When HAL_LCD=FALSE, VIRTUAL_REGISTERS decreases to 17. For reasons I don't understand, when the number of virtual registers in the project configuration is 28 or greater, VIRTUAL_REGISTERS=18 in the map file again.