Hi,
We've been developing our application using pc-ble-driver which communicates with a PCA10040 devkit with SD API v5.1 connectivity firmware. In this dev environment, we see no issues. On our production boards we cross-compile our C++ code using GNU toolchain for MIPS. As an example, we can cross compile heart rate collector and run HRC in OpenWrt on the production board.
However, it looks like there is an issue with printf being called inside ble_evt_dispatch of HRC on the production board that is not present in our dev environment. When scanning for and handling new advertisements, HRC prints the device mac address of the scanned device and then checks if the advertisement comes from a HRM device. When we remove the section of code to check the name of the device and only print the mac address, we see segmentation faults and junk data being printed.
My best guess is that the buffers aren't actually being flushed (despite the call to fflush(stdout)) before the next interrupt to handle a new advertisement, resulting in memory issues. If we add code to keep the device busy after the printf statement(s), similar to the name checks for HRM, this is not an issue. The output again appears to be fine.
Any insight to this? I'm not familiar with printf, but I recall that it shouldn't be used in interrupts. Were these used in heart rate collector just as an example? If so, I believe I can print from main after saving the appropriate data, but I have no way of protecting critical sections of shared memory between main and the interrupt.
EDIT
Upon further tinkering, I believe the issue may be in "ble_address_to_string_convert" (line 242). Since I'm using C++, I changed this function to create a std::string instead of a C string. I also avoided using sprintf and just append to the std::string. Now we aren't seeing segmentation faults or junk data being printed using printf and fflush at the end of the on_adv_report function.
