firmware modified mac address and advertising name

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

cross mob
JiWa_1379161
Level 3
Level 3
5 sign-ins 10 replies posted 5 replies posted

I have two BLE devices, one as central and one as peripheral. For the central device, I have the box checked to generate the mac address from the die. I have a need to read the full mac address of the central device within its firmware. Where do I find the mac address within all of the header and source file generated in the BLE library.

Secondly in the peripheral, I assigned an advertising name through the design block of the BLE module. I would like to change that name within the peripheral code so I can either add to the existing name or change it completely. Basically have a default advertising name then change to something else once some settings are established. I thought I found the data for this but everytime I build the code, it defaults back to original data in design block. How can I change the adversting name within the firmware?

Lastly, are there any good references or examples how to set up pin usage between an app and the peripheral device. I have a different project that requires usage of a pin and not sure how to implement.

0 Likes
1 Solution
Anonymous
Not applicable

Question 1: MAC address is a thread on the matter of getting the "mac" address of the BLE address of the device with program code. This will not be generated from software, but polled from the hardware when the program code runs, as the die values are written on each board differently, and the software can't know which hardware is running the code beforehand. (Possibly you could read it using a miniProg3 or something similar)

Question 2: I modify my peripheral advertisement data which is pretty similar if you want that instead (lower level usage). Otherwise, the function CyBle_GapSetLocalName(const char8 name[]) is the cypress API for changing the advertising name (while not advertising), or (since you wanted to be able to add to the name length) Project #009: Dynamic Broadcaster - Changing Advertising Packets | Cypress Semiconductor  has a good example on dynamic updates to broadcasting. Obviously you would need to modify the example to advertise instead of broadcast, but that should be a simple matter.

Question 3: It is really an application-specific need from what I've seen; A simple on/off button control would be the simplest, and then you just add layers/conditions to control the pin from more complicated functions if you have a more involved application. Simply create a characteristic/attribute with the pin value being 0 for off, and not zero for on (possibly byte value for the entire port control?). Then, read/write to the characteristic from the phone/central, with the peripheral handling the event of a write/read request event by setting the pin value or returning the value of the pin respectively.

View solution in original post

0 Likes
1 Reply
Anonymous
Not applicable

Question 1: MAC address is a thread on the matter of getting the "mac" address of the BLE address of the device with program code. This will not be generated from software, but polled from the hardware when the program code runs, as the die values are written on each board differently, and the software can't know which hardware is running the code beforehand. (Possibly you could read it using a miniProg3 or something similar)

Question 2: I modify my peripheral advertisement data which is pretty similar if you want that instead (lower level usage). Otherwise, the function CyBle_GapSetLocalName(const char8 name[]) is the cypress API for changing the advertising name (while not advertising), or (since you wanted to be able to add to the name length) Project #009: Dynamic Broadcaster - Changing Advertising Packets | Cypress Semiconductor  has a good example on dynamic updates to broadcasting. Obviously you would need to modify the example to advertise instead of broadcast, but that should be a simple matter.

Question 3: It is really an application-specific need from what I've seen; A simple on/off button control would be the simplest, and then you just add layers/conditions to control the pin from more complicated functions if you have a more involved application. Simply create a characteristic/attribute with the pin value being 0 for off, and not zero for on (possibly byte value for the entire port control?). Then, read/write to the characteristic from the phone/central, with the peripheral handling the event of a write/read request event by setting the pin value or returning the value of the pin respectively.

0 Likes