Welcome in the forum, Richard.
I would suggest you to update Creator to latest version (4.0). This will enable the newer devices.
Thanks Bob. I'm now able to program and run the sample apps (rookie mistake)
Unfortunately, the apps all hang up in the infinite loop in IntDefaultHandler after trying to start BLE. I'm guessing it's a configuration issue, but darned if I can find where. I haven't changed any of the code and the fault seems to be inside the stack for which there is no source.
psocHang2.JPG 161.5 K
Increase your Heap size to 0x200 that may help.
Post you code so we can check it.
Thanks for the suggestion but no go.
I increased the heap size to 0x800; results are the same - infinite loop in the IntDefaultHandler. Note that the while(1) is not the trap for ENOMEM error, but the else case. I added code to save the error number and in both the Device Information and FindMe examples, errno is 0. Curiously, running the temperature measurement example app, the error number is 0x58. But they all hang up in the same place.
What example are you using?
Take the error message seriously: Something definitively has gone wrong. When this happened before main() is called something with the oscillators went amiss. When past initialization you probably clobbered the stack.
Post your actual code, everything else is guessing.
Increasing the heap size to 0x0200 is not a cure for errors other than printing floats. It has to do with the float formatting of newlib nano which seemingly clobbers the heap. I found out when I tried to print floats under my "ARTS" rtos.
Below is the code that fails. I did not write this code, I'm just trying to run the example application (BLE_Device_Information_Service) that comes with PSoC Creator 4.0. The call to CyBle_Start() never returns because the code ends up in an infinite loop in the IntDefaultHandler(). Errno is NOT "ENOMEM".
Is it perhaps that I'm using the MiniPOrg3 debugger rather than the Pioneer dev kit?
const char8 serialNumber = "123456";
NEVER RETURNS FROM THIS FUNCTION
Not enough memory error? check your stack settings.
1. Errno is NOT ENOMEM
2. I've increased the stack and heap to 4kb each, it still hangs up.
Is there anyone from Cypress on this forum? I really expected development kit samples to work out of the box; am willing to troubleshoot the problem, but there's no source for the code which is failing.
Can you archive your workspace with the Project -> Archive Workspace/Project menu entry and attach it here? If it is a problem with the source somewhere, it will be reproducible on another device (e.g. my BLE Pioneer kit with CYBLE-212019-EVAL module). If it is a problem with your hardware, then your unmodified source should compile and run correctly elsewhere.
Thanks for helping. I've attached the 'complete' archive ('bundle' archive was too large to upload). I've also attached the output from the build process.
The only change I made to the example app is to increase stack and heap to 0x1000 each.
One possibly 'non-standard' wrinkle is that my project is not located in the default location suggested by the Creator. The Creator wants to put the project on one of our servers, but it fails to build there so I am have pointed the Creator to create the project on a directory on my local C: drive.
I compiled and flashed the project that you sent onto my CYBLE-212019-EVAL module (plugged into an original CY8CKIT-042-BLE kit), and it appears to boot and run correctly. The green LED blinks for a while, then eventually switches to solid red. While the LED is blinking, I am able to discover the device in a scan from CySmart and connect to it, and discover all attributes.
I confirmed with WinMerge that my compiled output is 100% identical to your compiled output, so it isn't anything unique on my machine. If you flash the same output .hex file onto your own module with either Creator or PSoC Programmer, and it does not run correctly, then I suspect a hardware issue with your kit or module.
Can you confirm:
- J16 on the Pioneer kit has a jumper selecting either 5V or 3.3V
- J15 on the Pioneer kit has a jumper connecting VDD to BLE_VDD
- J3 on the CYBLE-212019-EVAL module has a jumper connecting VDD to VDDR
These (or electrical equivalents) are all necessary for correct operation. Especially J3 could cause a problem for you; VDDD is required for programming, but VDDR is required for radio operation.