I have recently created a custom test board with a spot for the STM32F767ZIT6 with a spot for the STM32F767VIT6 nested under the ZI. I am trying to setup the CAN on the controllers using pins PA11/PA12 for CAN1, PB12/PB11 for CAN2, and PA15/PA8 for CAN3. On the ZI chip, the one board I assembled works fine. However, I have built 2 VI boards and the CAN does not work correctly, with both boards and all 3 CAN showing the same behavior. When connected to a PCAN-USB and using the PCAN-View software, it says the bus is heavy and they will not communicate with each other at all. When a NUCLEO-F767ZI is placed on the bus however, the nucleo can communicate to both the PCAN and custom VI board, but the PCAN and VI board still cannot communicate. Any ideas as to why this might be? I have been working under the assumption that the VI and ZI are essentially the same, just with a different pin count. I have been using the mbed CLI to compile for a custom target that was copied from the NUCLEO-F767ZI target, just set to use the external 8MHz clock instead
Then compare
targets_custom/TARGET_STM/TARGET_STM32F7/TARGET_STM32F767xI/TARGET_STM32F767VIT/PeripheralPins.c
with
targets_custom/TARGET_STM/TARGET_STM32F7/TARGET_STM32F767xI/TARGET_STM32F767ZIT/PeripheralPins.c
I can’t get that to work, running "python mbed-os/targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py -m “STM32F767ZITx.xml” doesn’t seem to do anything except generate me and empty .c and .h file. It gives me some sort of message, doesn’t say it’s an error though?
Traceback (most recent call last):
File “targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py”, line 1802, in
parse_pins()
File “targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py”, line 1305, in parse_pins
if “Variant” in s.attributes:
File “C:\Python27\lib\xml\dom\minidom.py”, line 522, in getitem
return self._attrs[attname_or_tuple]
Also, I’m not sure that it’s an error with the pin mapping. For some reason it’s working now, but only sort of. Sometimes messages make it through, in either direction, sometimes they don’t. Sometimes it works good for quite a while after a reset, and sometimes not at all. Is this something that is known about? Though it’s more likely something in my hardware or software is wrong…
I think something at the CAN level is wrong… Certain devices seem to refuse to send an ACK bit to the VI after a message is complete (what the PCAN is doing) and some do (the nucleo). Is that something that the difference between the ZI and VI might cause? Because the pcan sends the ZI an ACK bit just fine
