Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

PSoC™ 5, 3 & 1 Forum Discussions

shepdog87
Level 2
First solution authored 5 questions asked 10 sign-ins
Level 2

Hello,

I am using an external microcontroller to write to the bootloader on a PSOC5LP via the i2c interface. I have successfully compiled the .c files provided by Infineon for the bootloader and I can successfully write the new bootloadable image to the PSOC.

However, I am having a trial-and-error approach when it comes to delays between writes and reads.

The internal code for transferring data has no delay between the write and read.

I have found that if I do not add a delay after the write in the WriteData callback function, then the program will fail immediately because the PSOC does not have time to fill its i2c buffer before the external microcontroller calls the ReadData callback function.

I want to be able to program as fast as possible, so I started experimenting with different delays after writing. I found that if I use a delay of 15 milliseconds after each write, then the program-row reads all come back successful. However, I believe one of the last commands after programming is to verify the application, and it seems like the PSOC takes longer to respond to that command. If I use the delay of 15 milliseconds, which works fine for all rows, then the last command always fails because the PSOC responds with all 0xFF's (I don't think the PSOC finished verifying the application, or whatever function it was doing).

If I set the delay to 50 milliseconds after each write, then it successfully programs, and the last command passes as well.

However, I want to be able to program the new image as fast-as-possible, and it seems I only need that 50 ms delay for the final write.

What is the recommended method for i2c programming as far as delaying the read until the PSOC is ready? Is there a GPIO that could be toggled so my external micro knows that the PSOC has filled the i2c buffer?  The "TransferData" command inside the PSOC source files has no indication of what type of packet it is sending, so I am not sure how I could add logic to delay a different amount based on what type of command is being requested.

Is there an option inside the reprogramming source code for retry attempts?

Thanks,

Jason

 

 

0 Likes
1 Solution
shepdog87
Level 2
First solution authored 5 questions asked 10 sign-ins
Level 2

Hi all,

I think I might have solved this one. Originally, I was reading all of the bytes using the "read" command. However, if I didn't wait long enough sometimes I would read in the middle of when the PSOC was filling its data into the i2c registers. 

I looked at the PSOC programming documentation again, and noticed each command starts with a "0x01". By default, the i2c bus is pulled high, so if the PSOC is not ready, then the first byte will be "0xFF". So, instead of trying to read all bytes at a time, I just read one byte. If the byte is not equal to 0x01, then I will wait for 1 ms, and then try again. When it does equal 0x01, then I read the remaining bytes.

I am now able to successfully reprogram  the PSOC in 6 seconds.

Thanks.

View solution in original post

0 Likes
1 Reply
shepdog87
Level 2
First solution authored 5 questions asked 10 sign-ins
Level 2

Hi all,

I think I might have solved this one. Originally, I was reading all of the bytes using the "read" command. However, if I didn't wait long enough sometimes I would read in the middle of when the PSOC was filling its data into the i2c registers. 

I looked at the PSOC programming documentation again, and noticed each command starts with a "0x01". By default, the i2c bus is pulled high, so if the PSOC is not ready, then the first byte will be "0xFF". So, instead of trying to read all bytes at a time, I just read one byte. If the byte is not equal to 0x01, then I will wait for 1 ms, and then try again. When it does equal 0x01, then I read the remaining bytes.

I am now able to successfully reprogram  the PSOC in 6 seconds.

Thanks.

0 Likes