Simply trying to get print statement read out in putty. Device is connected to computer via USB connection.
Firmware has been updated.
Already checked port and pin is correct one for this hardware.
Code has not been changed. I have tired all baud rates.
Anyone I can trouble shoot this. I have no errors in the logs and nothing to tell me there is something wrong with the program. Is it possible the hardware is bad? I would appreciate any suggestions to trouble shoot.
I'm trying to aggressively use a hibernate mode and a WDT is intended to pull the CPU out of hibernation.
However, I need to preserve some data through the WDT reset.
Is there a keyword declaration to place certain RAM variables in an area of memory that does not get initialized immediately after a reset?
I'm aware of the .bss section of RAM. However after multiple searches among the compiler .h files, I could not find a declarative keyword that would force RAM variables to this area of memory.
I suspect I'm missing something obvious. Help would be appreciated.Show Less
I have a warning that's suddenly cropping up in a design and I'm hoping I can get some input as to why exactly it is occurring and hopefully how to clear it up.
I have some custom logic to dictate the behavior of a "Fault LED" as well as a status register using a PSoC5LP (CY8C5667AXI-LP040). The internal logic schematic is below:
The idea is that I have a FAULT_STAT register to see in firmware which faults have occurred, and a LED connected to FAULT_LED that is sticky so that if any fault occurs the LED will turn ON an remain ON until a power cycle/reset occurs. Any of the faults firing will cause a rising edge on the DFF and turn FAULT_LED high.
With this setup, I receive the following on build:
Warning-1350: Asynchronous path(s) exist from "FAULT_A(0)_PAD" to "KpdClk".
Warning-1350: Asynchronous path(s) exist from "FAULT_B(0)_PAD" to "KpdClk".
I'm not sure why this is being thrown. KpdClk is a 100Hz clock I am using mainly as a clock for the status registers that read in an external keypad. I am also using it in a few other spots such as an Edge Detector and as the source clock for a single-shot timer elsewhere in the design that should have no bearing on the issue here.
I guess I'm confused as to why this is an issue with FAULT_A and FAULT_B specifically. My first thought was maybe something about how I have these two signals controlling the CLK line of the DFF, but BN_FAULT is similarly connected as a way of controlling the DFF CLK, but the warning is not thrown for this pin. I guess I just am not seeing how FAULT_A and FAULT_B can have any relation to KpdClk, but BN_FAULT does not?
Here's a snippet info pulled from the Static Timing Analysis Document:
So what's actually going on here and how would I go about clearing up this warning? I can't share the entire project, but I can provide more details as necessary, if necessary.
I am trying to communicate with two PSoC 5LP MCUs using the fast method so that current functions won't be affected by the latency that happens due to the communication.
So could you please suggest a method to communicate between to MCUs?
Thank youShow Less
BOARD :PSOC5LP , CY8CKIT-059, float printing is not working with USB-UART -PSOC5LP
sprintf(charbuf,"%f\n",adc_volt) //adc_volt is float, charbuf is array
OUTPUT : Null
I'm using the CY8C3866AXI-040 in a design but I can't seem to find a supplier with out a lead time going out to 1 year+. The same family seems to have the CY8C3866AXI-039 which seems like a drop-in replacement (we don't use the CAN portion), but I couldn't find any information on any major differences between the two numbers.
Any information would be appreciated.
In a bootloadable project, I need to access CyResetStatus but it alwasy says CY_RESET_SW, regardless of how the chip reset.
This is caused by the the bootloader running on startup, which exits with CySoftwareReset(). This overwrites whatever was in CyResetStatus previously.
Is there a way for the bootloadable project to correctly determine the reset status as seen by the bootloader?
Put another way, is there a way for the bootloader to copy that information somewhere for the bootloadable to read? For instance, how could I create a NOINIT variable in both projects that would share the same memory location?
I've attached two really good docs that somewhat answer my question but not completely. The third .png doc shows an INL20 of +-32. Surely this must be a typo? What is the INL of the PSoC 5 when the 20 bit AtoD is used?
Same question for the enob on the PSoC 5? What is it? I realize it depends on a lot of things as the app note explains but most data sheets contain the enob info. It specced DNL and INL, power supply rejection ratio, and other parameters but no mention of enob.
I am using the PSoC5 I2C Multi Master Slave implementation and seem to be experiencing an event that causes the SDA line to go low and never return high. When this happens, an infinite while loop is entered from one of the autogenerated APIs from PSoC creator.
I have tried implementing some "fixes" although I'm not too sure how well they are working because I'm still getting failures.
My test is to basically have the code running and see how long it takes to fault(SDA line being held low) My code is talking to sensors, ICs via I2C at a periodic time interval. My "Fixes" have made it to where instead of failing within an hour, it takes about a day or two to fail.
I would like to share some of my "fixes" / Findings to ensure that I am moving in the right direction - ultimately I'm looking for some advice on how to recover the I2C when this event is happening. I would also like to know if there is more that I can do to narrow the problem to actually find what is happening to cause this issue.
This is a custom board with a CY8C5868AXI. I2C is configured with 1k pullups and has the following parts in the I2C bus:
- DS2484 I2C slave to 1Wire Master
- MCP9902 Temp Sensor
If I reset the PSoC using XRES (Pushbutton), the SDA line returns high and the fault goes away. After pushing the reset button from a faulted state, the issue does not appear to happen again. This makes me think that this may be some kind of first time power on issue, as the issue does not happen again after performing a hard reset. Software resets do not have the same effect - the SDA line remains low.
The pushbutton we have attached to XRES is only attached to XRES - that is, it is only resetting the PSoC5. This leads me to believe the issue is not with another slave device and that the issue is in the PSoC5.
The Signal integrity appears to be "good enough" - there is slight rounding, but could that be why at some point we see failures on the SDA line? We were experiencing some undershoot before adding RC to fix that. The undershoot would go below -0.5 volts - could this mean the part would now have reliability issues?
1. Before performing any I2C transactions, I use CyGlobalIntDisable / CyGlobalIntEnable - this is the latest item that I added - I haven't been able to stress test this, as I just did the change, so I will have to wait and see if this remedies the issue. Not sure if this is actually doing what I think it's doing - ensuring that once an I2C start condition has been successfully issued, it can not be interrupted by timers / interrupts, until the transaction is complete.
2. When calling I2C API, I conditionally call each successive function always ending with a stop. This was a major fix that greatly increased the reliability of the I2C:
3. In the I2C_Master.C file that gets auto generated, I modified the source in API calls that have an infinite while loop
Originally, the code is autogenerated to have the while loop empty, meaning that if the I2C_WAIT_BYTE_COMPLETE never returns "OK", the while loop will never be broken. So I wrote in a counter that allows the while loop to be broken if this event occurs. At first, I would just break from the loop, Then I added a "bus reset" function to try to help recover the SDA line.
The code circled in red is added by me, the rest of the code is autogenerated from PSoC creator.
4. The bus reset function is supposed to re-assign the I2C pins as Output Push Pull, drive the SDA and SCL high and low 16 times, then "reconnect" the pins to I2C.
This was the fix that made the code run for days instead of hours. I was almost sure that this would be the fix, but unfortunately I returned to my system to find the SDA line low some days later.
This fix was taken from another post, where the user reassigns the SDA as High Z and the SCL and Strong Drive, but I found it to work for me when assigning both SDA and SCL and strong drive and toggling both.
Thank you for your help with this issue,