|
|
Post by Admin on Dec 17, 2019 13:38:44 GMT
We will test your code on our rig. This may take several days to complete.
|
|
|
|
Post by Admin on Dec 17, 2019 13:56:36 GMT
Ok something really strange is happening. We will let you know when it is fixed!
|
|
jimmie
Junior Member
Posts: 86
|
Post by jimmie on Dec 17, 2019 14:11:47 GMT
We will test your code on our rig. This may take several days to complete.
Thank you.
Since my last message, I have deleted the Hitex folder and the aurduino and aurduino_dx folders and reinstalled ShieldBuddy IDE. The same problems persist.
It is also worth mentioning that the new IDE also broke the EEPROM of the ShieldBuddy. Now, the EEPROM will init successfully but then mostly hangs the system when trying to read its contents.
|
|
|
|
Post by Admin on Dec 17, 2019 15:36:57 GMT
We will fix it now we have your example!
|
|
|
|
Post by Admin on Dec 23, 2019 9:52:47 GMT
One problem we have seen is that you are using SerialASC.print from core0 and core1. This is dangerous! If you want to do this, you will need to use the Htx_LockResource() function. This potential problem is covered in the user manual section 2.5.2.1. Here is an example from your setup():
....
while(Htx_LockResource(&SerialASC.PortInUse) == Htx_RESOURCE_BUSY) { ; }
SerialASC.println(" S E T U P Completed");
SerialASC.println("==================================================================");
Htx_UnlockResource(&SerialASC.PortInUse);
We have added the Htx_LockResource() and Htx_UnlockResource() around all the SerialASC.* calls.
The program now runs even with multiple resets, using the new I2C driver.
Does this fix it for you too?
|
|
jimmie
Junior Member
Posts: 86
|
Post by jimmie on Dec 24, 2019 0:55:12 GMT
Thank you. I tried commenting out SerialASC.print statements in core 0, and compiled the code. Everything worked (i2c, FRAm etc.). I pressed reset several times and everything was fine.
I then recompiled the same code and I am back to square one. NOTHING works! The same situation as before, resetting the board, recycling power does not work.
Before the i2c change, SerialASC would indeed print garbage if written to from more than one core (I know this is also in the manual). However, what does this have to do with i2c devices(display and FRAM) not working?
I even tried commenting out SerialASC.begin(115200); and EVERY SerialASC.println statement in setup0,1,2. I also stopped reading from the FRAM and only tried the display. The display still does not work and the code stops at:
display.begin(SH1106_SWITCHCAPVCC, 0x3C);
While my knowledge is rather limited, I am about 100% sure this is something to do with the Wire library and timing. I do not think SerialASC.print has anything to do with it.
(BTW, fram.begin(); also stops code from progressing)
|
|
|
|
Post by Admin on Dec 24, 2019 8:24:41 GMT
It might be that the CPU sync code is not working properly. This came from the Infineon framework and we have never really tested it. It might explain the unreliability.
|
|
|
|
Post by Admin on Dec 24, 2019 9:41:52 GMT
The cpu sync code has a timeout of 1ms. This means that if the difference between core0 and core1 is greater than 1ms, the program will proceed. Core0 is much slower to get to setup() than core1 as it has to do all the Arduino environment initialisations and start cores1 and 2. I would try increasing the timeout value to 100 (100ms).
/* Cpu sync event wait*/
IfxCpu_emitEvent(&cpuSyncEvent);
IfxCpu_waitEvent(&cpuSyncEvent, 100);
|
|
|
|
Post by Admin on Dec 24, 2019 9:46:17 GMT
The old I2C driver did not support repeated start mode. The new I2C driver does support it. This is needed by the FRAM to allow the device ID to be read, although it does work for read and write without it. The Adafruit FRAM example shows this:
if (fram.begin(0x50)) { // you can stick the new i2c addr in here, e.g. begin(0x51);
SerialASC.println("");
SerialASC.println("Found I2C FRAM");
} else {
SerialASC.println("I2C FRAM not identified ... check your connections?\r\n");
SerialASC.println("Will continue in case this processor doesn't support repeated start\r\n");
}
|
|
|
|
Post by Admin on Dec 24, 2019 9:56:47 GMT
It looks like core0 and core1 could be accessing I2C devices at the same time. The fram.begin is on core0 and the display driver display.begin is on core1. The I2C driver cannot be used this way. This could randomly result in a complete hang-up of the I2C bus. The old I2C driver had a bus timeout in it which would possibly have masked this problem. The new driver does not. We would have to put a mechanism in the I2C driver to prevent simultaneous use of the single I2C peripheral from two cores at the same time. We will investigate this.
Could you not put all the I2C-related functions on just one core? You could move the display to different pins and use the software I2C driver.
|
|
|
|
Post by Admin on Dec 27, 2019 9:01:08 GMT
This is strange as there is no access to the I2C bus made in Wire.begin. Even if nothing is connected to the I2C, it should still run.
|
|
|
|
Post by Admin on Dec 28, 2019 11:03:31 GMT
|
|
jimmie
Junior Member
Posts: 86
|
Post by jimmie on Dec 28, 2019 16:02:42 GMT
Please make sure you are using this files:
I was using those same files but to check again I copied over the old files but same problem. BTW, I also tried FRAM again, also stops at .begin.
I am happy to try anything else?
==============================================================
Update:
I am suspecting a SDA bad connection on my custom board and currently investigating it. I will keep trying to make sure that this is not a repeat of the behavior from before where the board eventually stops working.
Thank you for your help. Please accept my apology if I wasted your time.
|
|
|
|
Post by Admin on Jan 2, 2020 8:51:36 GMT
Our rig here does the following:
TranTechCom LLC
Dimensioner Pro 4
0.0.0
Then:
Web pin: High
Measure pin: High
Reset pin: High
We can keep pressing the RESET button and power cycling the board and it always does the same. Is this the expected behaviour?
|
|
jimmie
Junior Member
Posts: 86
|
Post by jimmie on Jan 2, 2020 12:05:35 GMT
Yes, thank you. All working now.
|
|
