I am working with the CYBLE-416045-02 chip (with CY8CPROTO-063-BLE KIT) but i am declaring a function in my .h file as the following:
uint8_t WriteCommandPacket(uint16_t cmd);
and the user can send differents commands:
#define CMD_WATER (0x3608)
#define CMD_ALCOHOL (0x3615)
#define CMD_STOP_MEASUREMENT (0x3FF9)
#define CMD_SOFT_RESET (0x0006)
#define CMD_READ_I (0x367C)
#define CMD_READ_II (0xE102)
it is why i am using the uint16_t type to send this command. But the PSoC Creattor 4.4 is telling me the following error:
masterI2C.h:68:9: error: conflicting types for 'WriteCommandPacket'
uint8_t WriteCommandPacket(uint16_t cmd);
The strage thing that i can use this type inside of the functions
Can someone help me out?
This is the first time I have made a custom PCB for PSOC-6 device. I had been using PSOC-4 and 5 till date. Mistakenly the VDD_NS pin has been connected to GND instead of 3.3V. I am using Kitprog to program the device using SWD however I get a programming error. The device number is CY8C6137BZI-F54.
- Is it OK let the VDD_NS pin at 0V if we configure to use the LDO instead of SIMO buck?
- Is it possible that the programming error is because of the VDD_NS pin being connected to 0V instead of 3.3V? (I have configured the system settings for LDO and not SIMO)
Thank youShow Less
A few weeks ago I posted a message here complaining that Cy_TCPM_Counter_SetPeriod() is not behaving as documented. In my application I need to dynamically change the period of a counter anywhere from 1 to 400 Hz to generate a periodic interrupt that will trigger other events. The problem was that no mater what period I tried to set, the counter ignored it and remained running at the initial frequency when it was initialized. Frustrated I resorted to just de-initialize and reinitialize the counter with the new frequency. A few weeks later the problem came back to bite me again when I needed to change the period of a timer in PMW mode, and posted a second message here.
After detailed code review and debugging, and stepping through the code, I finally found a few errors in my code, AND, understood how the API really has to be used. This is not clearly documented anywhere, at least in the places where I looked (this forum and others).
First, don't repeat my errors:
1. Pay attention to the type of parameters that each function expects. For example,
Cy_TCPWM_TriggerStart_Single(Timer_1_HW, Timer_1_NUM); // The second parameter must be the timer NUMBER
Cy_TCPWM_TriggerStart(Timer_1_HW, Timer_1_MASK); // The second parameter must be the timer MASK (or the OR '|' combined mask of several timers, if you want to start them all in sync)
2. Double check the parameters used in the PDL documentation. In one instance the example has the second parameter incorrect (it uses counter MASK where it should use counter NUMBER, twice!). All xx_Single() versions of the functions work on a single timer and expect the timer number. That error in the example led me to believe that xx_MASK and xx_NUMBER are interchangeable, when they are NOT.
3. You must STOP the counter to make changes to the period, duty cycle, compare values, etc. There may be instances where this is not necessary, but better safe than sorry, in the PDL documentation the examples do not mention this, (at least for the functions that I used).
4. It seems that Cy_TCPWM_TriggerStopOrKill_Single() is not an atomic operation. You must test and make sure that the counter has stopped before continuing. This was the principal problem I had since the beginning.
So, here is the the safe method to alter counter parameters that I came up with:
uint32_t loops; // this variable is for debugging purposes only
void Change_Timer_1_Frequency(uint32_t _new_frequency)
uint32_t period = 0;
/* validate frequency range */
if (_new_frequency < MIN_FREQUENCY || _new_frequency > MAX_FREQUENCY)
period = _Timer_1_clock / _new_frequency;
loops = 0;
/* IMPORTANT: wait for the timer to stop before changing registers */
while (Cy_TCPWM_Counter_GetStatus(Timer_1_HW, Timer_1_NUM) & CY_TCPWM_COUNTER_STATUS_COUNTER_RUNNING )
Cy_TCPWM_Counter_SetCounter(Timer_1_HW, Timer_1_NUM, 0);
Cy_TCPWM_Counter_SetPeriod(Timer_1_HW, Timer_1_NUM, period);
I introduced the variable Loops for testing purposes. In a simple, Hello World type of program when only this code is running Loops may be 0, most of the time. But as the program grows in complexity with interrupts and external events going on at the same time, that won't be the case. In my application Loops ends up anywhere from 65 a to over 600 iterations before the counter stopped!
In summary, I thing that PDL is a good helper, but its documentation is minimal and the examples just snippets not really tested in an actual program. As a former boss of mine used to say "Trust is good, check is better!"
Hope you are good. Did anyone has example of any temperature sensor with it's .c file written in freertos?
I am trying to write it but facing a problem. Can anyone help me on this ?
Ali ShoaibShow Less
In the description of cyhal_i2c_master_write():
"I2C master blocking write.
This will write
size bytes of data from the buffer pointed to by
data. It will not return until either all of the data has been written, or the timeout has elapsed"
Will this function also block the interrupts (e.g. uart, timer ) until it finished?
MCU CY8C6347BZI-BLD54 is used as a CPU on our product and it has been produced for 50K-100K units. However, there are a few units (less than 1%) having boot-up issue after executing the process of secure boot. The failure symptoms are listed below:
1. Power up for several cycles and then finally it could boot up successfully. The cycle time of powering up can't be calculated. It's a random.
2. Always fail to boot up so it becomes a brick.
3. 1 unit succeeds to boot up intermittently.
The eFuse of these units is burned successfully if we check the eFuse bit after the unit succeed to boot up. Thus, we can't read any debug information from the SWD port. Then some signal waveforms are captured and compared on both the situation of successful and fail boot-up. The main differences are
1. The power rail behavior of MCU_VIND2, MCU_VRF, and MCU_VBUCK1
2. The activated timing of SWDIO
Please refer to the attachment for more detail waveforms. We suspect this issue results from the process of eFuse burning but we don't have solid evidence to prove it. Thus, we need your thoughts and insights on this issue. It's getting more critical now due to the increasing production volume. Thanks.Show Less
Does any one really know why this error pops up: Cy_BLE_GAP_GenerateKeys returns API Error: 0x160004 CY_BLE_ERROR_INSUFFICIENT_RESOURCES ?
In the documentation we can find "If BLE Stack resources are unavailable.". What resources is this line referring too? We use an app with OTA over BLE and everything is fine expect there are moments when we received this error.
Any hints would be really appreciated!
I pre-ordered this CY8CKIT-062-BLE dev board from Digi-Key and it was shipped 28-SEP-2017 Inv # 59555866.
It won't program. I've tried the on-board Kitprog and a Miniprog. I've updated the KitProg using PSOC Programmer. I've tried updating via fw-loader. Nothing works. From within PSOC Creator 4.4, Kitprog says it programmed. The miniprog won't program from within PSOC Creator 4.4.
I looked at the silicon and it says "ES" as in "Engineering Sample" CY8C6347BZI-BLD53ES1725 62 5565. The board sticker says "121-60367-01 Rev 08" and "1732SO00102". I read online there were issues with the early versions of this board and to contact support. I sent a message via the Infineon website but I'm not sure that it went to the right place.
Is there something I can do to make this board usable? I know it's been a long time... I just recently got back into working with motor controls and I need the features present in the PSOC 6.Show Less
DFU may fail depending on the version of android on the host.
For example, it works fine on Android 9, but it doesn't work on Android 12.
Do you have application notes or forums that explain it?
Do you have any application notes about DFU's Fail Safe?
In particular, if there is a recommended implementation method for applications where peripheral does not have an interface such as a reset button, please let us know.
In the case of an application without an interface, the device cannot be reset from the outside, so if there is a bug in the uploaded firmware and it becomes impossible to DFU again, it will be irreversible.
It would be helpful if there was a document that explained tips etc to avoid such cases.
Yutaka MatsubaraShow Less
We are using the CYBLE-416045-02 module in a doppler radar speed collection
module that sends traffic speed data to a server. We have a half dozen
units in the field for testing and the system is running very well.
An external FRAM is being used for parameter and system state saving during
processor hibernation. For system reliability we want to also save the
parameters in PSoC 6 flash using the EEPROM V2.20 component. Creator 4.4
is being used for development.
The "Em_EEPROM" component was first configured with 1024 bytes, redundant copy,
blocking write and no wear leveling. Auxiliary audits were added to see the
results of the writes and reads on the EEPROM. At first nothing went through;
even the initialization returned a CY_EM_EEPROM_WRITE_FAIL. After
various trials with the configuration, a number of writes and reads
went through with no redundant copy and non-blocking writes. After more
experimenting, I could not even get that case to work any more.
Also, when the EEPROM component is active none of the ipc functions which are
used to communicate between CM0p and CM4 were working any more.
So, the EEPROM component must be interfering with the ipc operation.
To check this further, a compiler conditional variable was added to
be able to comment out the new EEPROM interface code. When
the EEPROM was allowed to be compiled in, the system did not
work. When it was not, the system worked as well as before starting
to add the EEPROM.
So, the problem is what should I be doing to prevent this interference.
The documentation for EEPROM does not say anything about such
interaction and I do not know what internal chip resources the
EEPROM is using that might be colliding with those used by ipc.
This should not have to be known to the user.
Also, the documentation for the EEPROM component is much too sparse.
For example, writes can be in non-blocking mode. Normally when
this is provided, there is a way of starting the operation and a
way of checking when the operation is done. There is no information
about this in the EEPROM documentation.
A second example is the return codes. Sure, they are defined. But,
what the user needs to know is why did a write error appear and
what should be done to fix it.
The only EEPROM calls used in the interface are the following:
fnvm__status= Em_EEPROM_Init(0); // address not used in PSoC 6
fnvm__status= Em_EEPROM_Write((U4)ind,(V *)vUP,(U4)nb_used);
fnvm__status= Em_EEPROM_Read((U4)ind,(V *)dUP,(U4)nb_used);
The following are the ipc calls used in the CM0p and CM4 processors:
, (void *) &ipc0__ipc_msg
, (void *) &ipc4__ipc_msgT