I’m testing a M40 Powerlink brick module (AB6711-C) connected to the host CPU via SPI. I’m using the host application example project. With macro ABCC_CFG_INT_ENABLED set to TRUE application fails with a watchdog timeout error. Setting ABCC_CFG_INT_ENABLED to FALSE everything is fine.
I checked with a scope and nIRQ pin (pin 9) never goes down after reset is de-asserted.
Is there any way to command that pin to go up/down. Any test/debug command?
Thanks in advance
Carlo
Hi Carlo,
Just because of the time difference, I’d recommend creating the case here for local support in your region:
But are you saying that if you take a look at a scope capture of this, that the nIRQ never toggles when you hit the reset button?
-Tim
yes, nIRQ never toggles. Maybe the module is damaged?
Is there any particular condition that could prevent nIRQ from toggling?
Do you have a starter kit as well so we could test if it’s an issue with the M40?
Unfortunately no. I have no starter kit.
By the way, the module now requires a voltage > 3.5V. If I power it with 3.3V the module signals 99% times exception state. Is this ok?
Hi Carlo,
Where are you seeing this new voltage requirement? according to our documentation it should be between 3.15 and 3.45 V?
My fault! I forgot to connect the 50pins connector shield to ground! Now everything runs smoothly with 3.3V
nIRQ is still broken though 
by the way, I tried to enable SYNC signal and it works! So it’s only nIRQ…
Could you send us the wiring diagram for how you have the nIRQ connected?
I have connnected all pins following your document HW design guide, paragraph 3.4.2 Pin Usage in SPI Mode, with the following notes:
all DIP switch pins are not connected
all LED interface pins are not connected
pin 43, not connected
pin 18, not connected
pin 28, not connected
pin 9, nIRQ - first I left it not connected and I tried to monitor it on the scope. Then I connected it to one input pin of the HOST CPU (I’m using a STM32H7 NUCLEO 144 eval board) this way:
GPIO_InitStruct.Pin = nIRQ_Pin;
GPIO_InitStruct.Mode = GPIO_MODE_IT_FALLING;
GPIO_InitStruct.Pull = GPIO_PULLUP;
HAL_GPIO_Init(nIRQ_GPIO_Port, &GPIO_InitStruct);
In both cases I have no toggling on nIRQ pin after a module reset.
One final thing:
Maybe the problem is that contact not connected?
I’d recommend taking a look at this document.
Hi @CaNe,
Can you verify that your application can run when not using ABCC_CFG_INT_ENABLED? In other words the application reaches NW_INIT/WAIT_PROCESS/etc.
If it is not getting past SETUP state can you check the following:
Is the chip hot to the touch?
Is an external pull-down resistor present on the ABCC reset line? (An internal pull-down from the MCU is not recommended)
Is there sufficient 3v3 power to the ABCC?
I connected pin 28 to 3V3.
This is what I can see at power-on:
Signal 1 in Yellow is nIRQ
Signal 2 is the reset PIN
I’m giving a 5ms reset pulse after 50ms, to be sure that the module will catch it. And it works.
The only, thing, as you can see, is that nIRQ never toggles…
Carlo
Yes, the application runs perfectly with ABCC_CFG_INT_ENABLED set to FASLE
Hi @CaNe,
Here’s what my colleague said to me
We were wondering if there’s any known underlying issues with the IRQ signal that might be worth looking into with this type of unit.
Also note that a pull-up resistor needs to permanently wired up to the IRQ. The IRQ is a normal GPIO pin on our side, it is floating while the ABCC is in RESET, and if there is no pull-up resistor to stabilise it in the inactive state between when the RESET deactivated and the ABCC has booted up and assigned a high level to it any noise might be interpreted as a low signal on his side, and then his microcontroller will start talking to the ABCC too early. This is not the cause of the present problems though, the oscilloscope image confirms that since the IRQ goes high but never low, but it might be an issue further on if this resistor is not already there.
Also, the IRQ goes low appr. 85ms after the RESET is deactivated, with SPI being used, on an ABCC40-ECT I have here, so the EPL should not be too far from that.
Is there any particular condition that could prevent nIRQ from toggling?
No, not apart from hardware-level issues or an incorrect Operation Mode.
If I power it with 3.3V the module signals 99% times exception state. Is this ok?
It is not that he gets a ‘Fatal’ immediately at RESET deactivation rather than an EXCEPTION at a later time? (Double-check the LEDs, one solid red LED -> EXCEPTION, two solid red LEDS -> Fatal.)
If the Operation Mode pins have an illegal combination the ABCC should go to Fatal more or less immediately when the RESET is deactivated.
My fault! I forgot to connect the 50pins connector shield to ground! Now everything runs smoothly with 3.3V
Should not matter unless there is something strange going on with the power pins. If all of the power pins are properly wired up he should not need the GND spring just to get things running. That spring is more for EMC stability. It might be an idea to have a closer look at the power supply connections.
all DIP switch pins are not connected
all LED interface pins are not connected
That should be corrected in the final version of their board. No inputs on the ABCC should be left floating, they must be tied to stable inactive level. And the active-low open-collector/drain outputs should also have pull-up/down resistors to give them a stable voltage in the case the ABCC does not presently drive that output.
Hello,
I checked with the Italian sales account manager (he provided me the module I’m using) if they have another module for replacing the one I’m using. Unfortunately they have nothing in house. Anyway, I will have to evaluate also the Profinet IRT version of M40, still the brick module. So I’ll order one and when I receive it I will connect it to my setup, without changing anything. Same connections I have now
Should nIRQ signal toggle with the new module, then we’ll know that probably the current module is broken. Otherwise we’ll know that something is wrong with my setup…
I’ll keep you posted as soon as I have news
Carlo
Ok thanks for the update. Also we wanted to check if you were able to open a support case on mysupport.hms.se to work directly with the support team in your region?
