OTA & Scan Response Packet

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
MikeAustin
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

I have an application where I am using the Scan Response Packet to transfer data between my peripheral and a client quickly, without the need for a connection to be established.  This all works fine

But I want to implement this in a Fixed Stack OTA project, and no matter what I try, the Bootloadable code that makes a call to 'CyBle_GapUpdateAdvData' won't compile without an error.  The compiler kicks up an error claiming that that API doesn't exist, even though I've followed all of Cypress's documentation to correctly link the BLE code generated when I compile the Bootloader (which has the BLE component) to the Bootloadable code.

I think (now, keep in mind I'm a hardware engineer let loose on the firmware, so I could well be wrong) that there is an issue in the way the mk.bat and cm0ggc.ld files in the Bootloader are configured, meaning the appropriate API's generated in the Bootloader aren't included when the Bootloadable code is compiled.

I'm having a similar issue with any of the API's that are used to provide Current Time Service functionality, which means the part of my project that needs the CTS functionality is also bombing out at compile time, but I've stripped that out in the short term to focus on trying to establish why the Scan Response Packet API isn't working.

So, my question firstly is:

1.  Has anyone on here successfully implemented an OTA version of a project that utilises the API CyBle_GapUpdateAdvData?

2.  If so, did you have to make modifications to any of Cypress .bat or .ld files to get it to work?

3.  If you did, what were those mods?

 

Thanks and regards,

Mike

0 Likes
1 Solution
MikeAustin
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

Solved this myself in the end (is it just me, or has this forum turned into a bit of a void since Infineon took over Cypress??)

I needed to modify the cm0gcc.ld linker file in the Bootloader project to add a bunch of KEEP statements to prevent all the BLE API's I needed in the Bootloadable project from being stripped out when the Bootloader project was built.

You can also achieve the same result by changing the "Remove Unused Sections" of the Linker Optimization in the Build Settings of the Bootloader to FALSE, but this then stuffs absolutely every API known to man into your Bootloader code, and chews up a whole heap of RAM.

View solution in original post

0 Likes
2 Replies
MikeAustin
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

Have progressed this a little further on my own.  Looks like as a result of having the Build Settings>Linker>Optimization>Remove Unused Sections option for the Bootloader set to TRUE, its stripping out a bunch of BLE API's I actually need, including the CyBle_GapUpdateAdvData one.

If I set that to FALSE, I can see the API included in the BootloaderSymbolsGcc.ld file for my Bootloadable code.

But this then pushes my total SRAM useage out, as its including absolutely every BLE API ever invented, and I run out of RAM 😞

So, what I need to work out is:

1. How do I tell the Linker not to strip out API's that I actually need for my Bootloadable project?  Where in the Build Settings options do I get to tell it this? 

Thanks and regards,

Mike

 

0 Likes
MikeAustin
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

Solved this myself in the end (is it just me, or has this forum turned into a bit of a void since Infineon took over Cypress??)

I needed to modify the cm0gcc.ld linker file in the Bootloader project to add a bunch of KEEP statements to prevent all the BLE API's I needed in the Bootloadable project from being stripped out when the Bootloader project was built.

You can also achieve the same result by changing the "Remove Unused Sections" of the Linker Optimization in the Build Settings of the Bootloader to FALSE, but this then stuffs absolutely every API known to man into your Bootloader code, and chews up a whole heap of RAM.

0 Likes