PSoC™ 5, 3 & 1 Forum Discussions
I'd like to be able to use Bootloadable_1_SetActiveApplication()
But my current project is missing some settings that I don't know where to set.
What does it take to get a project to set the CYDEV_PROJ_TYPE to CYDEV_PROJ_TYPE_LOADABLEANDBOOTLOADER?
Is it some project setting, am I missing a setting on the bootloadable component?
Any help would be appreciated.
Show LessThis is a excerpt from Bootloadable_1.h
/*******************************************************************************
* API prototypes
*******************************************************************************/
#if (CYDEV_PROJ_TYPE == CYDEV_PROJ_TYPE_LOADABLEANDBOOTLOADER)
uint8 Bootloadable_1_GetActiveApplication(void) CYSMALL \
;
cystatus Bootloadable_1_SetActiveApplication(uint8 appId) CYSMALL \
;
#endif /* (CYDEV_PROJ_TYPE == CYDEV_PROJ_TYPE_LOADABLEANDBOOTLOADER)*/
Hi,
I am bit confused about the word select period. The I2S module data sheet says about bit resolution as "This parameter determines the number of data bits configured for each sample. If the Static Bit resolution is selected, this value can be set between 8 and 32." For example, I decided to use 16 bit for each sample, so my data bits should be 16 bits. Now what is the word select period?
From data sheet, "This parameter determines the period of a complete sample of both left and right channels. This value can be set to 16, 32, 48, or 64 (default)". So in my case it is again 16, I believe I2S send send data as <I2S Left Sample><I2S Right Sample><I2S left sample>....
So why there two parameters to set?
Show LessHi,
I am trying to write data to a port and then using a latch signal. But some of the port bits are changing later than the latch signal as shown in the picture below:
The first four from the bottom are address and the last one is the latch (WR_N). The problem here is: the latch closed before loading the data.
void MUXSetAddress(uint8_t address)
{
MUX_Addr_Write(address & 0x0F);
MUX_EN_Write(1);
CyDelayUs(1);
// Enable write
MUX_WR_N_Write(0);
CyDelayUs(1);
MUX_WR_N_Write(1);
MUX_EN_Write(0);
}
All are from same port, where the address is p[3:0].
Show LessHello,
What would happen on the PSoC 5LP if a pin configured as strong drive is shorted to the opposite level. In other words, what happens if it is shorted to ground while driving high and shorted to power (3.3 V) while driving low? Does the whole chip blow up? Reset? Otherwise, does the pin permanently become unusable? If so, in a high impedance state?
Thanks,
Show LessI have a Freesoc from SparkFun, and a part from digikey that we put on our product PCB, and they look significantly different.
Here is the Freesoc part: Imgur: The magic of the Internet
And here is our PCB : Imgur: The magic of the Internet
The logos are very different, and some of the other markings are significantly different as well. There is also some flaws in the plastic that make me dubious as well.
No matter what I do I cannot program that chip. I've verified my programmer works on the freesoc, but our PCB will not respond.
Does anybody have any ideas?
Thanks
--Greg
Show LessI'm having a hard time beginning a communication sequence between the PSOC and a BNO080 IMU.
I've created a send_packet function based on what the BNO datasheet says is supposed to happen, however all I've been able to observe on the scope is both the SCL line and SDL line going low.
This is my send packet function:
//BNO080 FUNCTIONS
void BNO080_sendPacket(uint8_t channelNumber, uint8_t dataLength) {
UART_PutString("Beginning of send Packet sequence\n");
uint8_t packetLength = dataLength+4; // adding the 4 header bytes
//debugging tool
char Buff[20];
sprintf(Buff,"d=%d\n", packetLength);
I2C_MasterSendStart(IMU_Address, I2C_WRITE_XFER_MODE);
I2C_MasterWriteByte(packetLength);
UART_PutString("First write command sent\n");
I2C_MasterWriteByte(packetLength >> 8);
UART_PutString("Second write command sent\n");
I2C_MasterWriteByte(channelNumber);
UART_PutString("Third write command sent\n");
I2C_MasterWriteByte(sequenceNumber[channelNumber]++);
//Sending the User's data packet
for (uint8_t i=0; i < dataLength; i++){
I2C_MasterWriteByte(shtpData);
}
I2C_MasterSendStop();
UART_PutString("Packet sent\n");
I've attached my current code the relevant components are the BNO080.c and main.c!
Let me know if anything is unclear.
Thanks for your help
Amilcar
Show LessHello!
I'm having some issues with using Master I2C on a PSoC5LP. I'm working with a FM24C16B I2C FRAM and I'm finding that my I2C bus with this FRAM is sometimes coming up with either one or both signals low. The problem comes when I'm running with debugger attached (MiniProg3) then attempt to reset (Shift-Alt-F5) , it will frequently result in I2C being stuck with either both lines or one line (usually SDA) being held low, and I can't seem to get the bus back into idle state until I power cycle the entire board.
I have 2k resistors for pull-ups and the I2C pins are both set as Bidirectional Open Drain Drive Low with Initial Drive State set to High. The FRAM is the only device on this I2C bus, so the only thing I can imagine happening is maybe the reset is occurring during a transmission and the FRAM is holding SDA low. This should not be occurring though, as the only time I am accessing the FRAM is on bootup, or when I send serial commands to write it from a host PC.
Does someone maybe have a way I could ensure SDA and SCL are initialized to a correct idle state upon startup? I tried doing a "dummy" transmission (just a start condition to address 0x00 followed by a stop condition) after calling I2C_Start() thinking that would get the bus back to idle but this has not worked. This in theory should not be an issue in production as there is no situation (other than maybe entering the bootloader) where the PSoC will be resetting while the system keeps power, but in testing it's proving to be rather annoying to have to constantly power cycle the system when I only want to reset the PSoC in the debugger.
Any suggestions would be appreciated,
Thanks!
[EDIT]
I have found (via logic analyzer) what looks to be happening is that when I attach the debugger or reset via debugger, some code runs before it brings the PC back to 0 and breaks at the beginning of main(). It looks like sometimes this can occur in the middle of an I2C transaction with the FRAM, leaving the bus in a non-idle state. Presumably the FRAM is holding SDA low while waiting for a clock from the PSoC. Putting a 1 second delay before I2C traffic begins looks to "solve" the issue, but any other suggestions to ensure the bus is idle on bootup would be appreciated.
Show LessI am running the ADC_SAR_Seq Example project as is with no modifications. I have the 5/3.3v selector on the psoc5lp dvk set to 5v as instructed. When reading the voltages on the DAC pins with a multimeter they read dead on however the LCD screen reads them slightly off. Here are my results
DAC Setting | LCD DISPLAY | Multimeter reading |
---|---|---|
0.192 V | 0.22 V | 0.192 V |
0.400 V | 0.44 V | 0.400 V |
0.592 V | 0.67 V | 0.592 V |
0.800 V | 0.88 V | 0.800 V |
4.000 V (Custom) | 4.28 V | 3.999 V |
Hopefully I am missing something simple.... any ideas? Also, no need to attach the project as its from the code example. running psoc create 4.2
Show LessHello,
I am currently working on the CY8CKIT-059 to interface with an external PSoC 4 MCU (CY8C4014SXI-421; 16-pin SOIC). But since the external PSoC 4 doesn't have an external reset pin (XRES) like other PSoC 4 packages but only has an internal Reset Pin on port P1_6, whereas the SWD interface from the Kit Prog board of the CY8CKIT-059 has a reset, I thought of checking whether using the SWDIO, SWDCLK and GND pins to interface the external PSoC 4 from Kit Prog can provide a complete interface to program the device. I am also using an external power supply to the PSoC 4 as it uses a 3.3 V and is not using the VTARG (5 V) pin on the Kit Prog board.
Please kindly advise me regarding this concern.
Thanks & Regards,
Nandhini Jayapandian
Show LessI'm having this weird issue in which my float prints get messed up when I print after running I2C commands! I've done the heap changes [now set 0x1000] and set the -u_printf thing to true. When I simply try to print out a float value it works fine, but when I add my I2C functions my float prints get messed up.
Please See attached pictures of what I'm seeing when I run just printing out floats vs printing out float after receiving I2C data packet (the I2C data packet has nothing to do with the float I'm spitting out).
I've also attached my project. The difference between the 2 terminal outputs are coming from commenting and uncommenting the BNO080_dataAvailable function
Has anyone seen this before? Is there anything I'm missing?
Thanks
Amilcar
Show Less