CC1310: using CC1310F64 with wMBus Protocol Software

Hi,

Thank you for your answer Siri.

I tried to build a 64kB Version of the APL_CC13xx_Meter_T1_C1. I made some changes in the linker command file (.cmd) and the problem seems to be at the line with the stack-size, so the RAM is the limitation !?

--stack_size=2048   /* C stack is also used for ISR stack */

I changed it to 1024 and CCS builds a 64kB version of that wMBus example without showing any errors or warnings. But the program does not run on my CC1310F64.

Maybe you are right, and the stack with the lib is to big for a 64kB pogram, but why can I change it and build it as a 64kB .bin file without any error messages?

Is there any chance to reduce the stack_size ?

Best Regards

SB

My further research on the Memory Configuration shows, that a build for a CC1310 F128 with 128kB Flash needs the following memory (copied from the .map file):

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  FLASH                 00000000   00020000  0000dc8a  00012376  R  X
  SRAM                  20000000   00005000  00004118  00000ee8  RW X

Looking at the "used" FLASH 56 458 B would fit in the CC1310 F64 with 64 kB Flash, right?

So looking at the "used" SRAM it needs 16 664 B, right?

And the CC1310 F64 with 16 384 B space ist to small for that.

Maybe these 280 B can be reduced anywhere, so it fits ... Do you have any idea?

Best regards

SB

Thank you for trying to help so far.

The example APL_CC13xx_Meter_T1_C1 with a reduced stacksize (1024) and even with reduced Flash and RAM runs on a CC1310 LaunchXL. So I think it should be possible to run it also on a custom Board with a CC1310F64.

I can flash it on our custom board but it does not send any packets. I tried to debug but it did not help a lot, because the most important actions happen in the stack.

Siri said:

What I do no is that there are no plans to try to update the WMBUS deliverables from  Stackforce to run on the F64 devices. I do not know if it is possible for the user to do modifications to have it run on F64.

Is there anything else in the wMBus Stack I need to change für moving it from a Launchpad to a custom Board with a CC1310F64?

The HAL, at least the Board.h and CC1310_LAUNCHXL.h and .c should be no problem because our custom board hardware is very similar to the launchpad and I can run the rfPacketTx example from the sdk on our custom board without changing the hal. So our custom board can send packets via the the rf and I can read them with a Launchpad and SmartRF Studio.

Best regards an thanks

SB

I assume you have remembered to change the FLASH_SIZE and RAM_SIZE in the .cfg

/* The starting address of the application.  Normally the interrupt vectors  */
/* must be located at the beginning of the application.                      */
#define FLASH_BASE              0x0
#define FLASH_SIZE              0x10000
#define RAM_BASE                0x20000000
#define RAM_SIZE                0x4000

Siri

Yes I did change that. And I also change my target configuration file (ccxml) to the target I want to use CC1310F64.ccxml. And I disabled all GPIOs to avoid unwanted signals. I used the chapter 12 of this file for help with the custom board and this site for the initial board bring up, even if its not the wMBus Stack and another board it will be similar, I think.

if you turn off optimization, you should be able to step through the code (you can do this both on the LP and on your custom HW), and hopefully that comparing the two would you should be able to figure out where your code fails. Also, how can you disable all GPIOs. Aren't the example using GPIOs to wake up from SLEEP?

Siri

Thanks for the hint with the optimization I turned it off and it helped.

At the moment my workflow is as follows:
I change something in the code, test it on the Launchpad and if it works I test it on my custom board. So I am quite sure that deactivating GPIOs will not influence the functions.

I found some more target specific files: in src/hal/target at least the target_config.h must be changed. There is a sector in the flash defined as page 30 but we do not have so many pages on a F64. And at the end o the file it is also possible to disable the usage of the sleep_PIN.

Today I am stucked with debugging on my custom board at src/hal/target/CC13xxLaunchPad/wmbus_hal.c in the function wmbus_hal_init. After making some changes I was able to go successful throgh the if where the mcu is initialized but now I stuck at the initialization of the rf frontend. It does not even give a return value, it is just hanging there. And for now I dont know how to debug of fix it because its nothing from the HAL.

With CCS10 I am able to load and run the rfPacketTx on my custom Board, so there is no problem with the Board or the rf frontend of the board.

Best regards and thanks

SB

Hi

Not sure how I can help you as I do not have any F64 devices and cannot test what you are testing.

What function (in what file are you stuck in when you say you are stuck in the initialization of the rf frontend)?

Siri

Maybe we do not concetrate on the point where I stucked but on the basic question. Also because you do not have the hardware to test.

I would like you to answer:

Is it possible to use the wmBus Stack on a smaller MCU like the CC1310F64?

Maybe there are recommendations from you as TI or from StackForce as the developer. Is it written or optimized for MCUs with 128kB or is the StackForce wMBus Stack/Lib independent of any MCU size?

Of course things have to be changed when using another hardware but maybe there are functions or configurations in the Stack/Lib which I cannot see and change but which only work on 128kB devices. This could be answered by StackForce or by TI because StackForce developed it and you "bought" it to use on your MCUs.

Thank you so far for your help

SB

I have contacted SF and are waiting for their feedback.

BR

Siri

Hi

according to SF it should be possible to get it up and running on an F64 device, and they could not think of anything done in the LIB files to prevent this.

Unfortunately they do not have F64 versions of the device either, so they cannot test it.

However, they did not think reducing the stack_size frmo 2048 to 1024 was the way to go, as this would be to small. They suggested that you rather tried to reduce the HEAPSIZE from 0x1000 to 0x200.

BR

Siri

Hi Siri,

thank you very much for your research and your answer.

Thank you also for the hint with the HEAPSIZE, it helped a lot. I did not receive any packet but I will continue trying. Now it is also pissible to build the other wMBus examples as a 64kB version.

With this you resolved my issue. But if it's ok for you, I would leave this thread open, so when I find a solution I would share it here.

Best regards

SB

I am glad to hear that you are making progress and please share if you get everything up and running, as this would be useful for others as well.

BR

Siri