XMC4500 ERU GPIO - some pins do not work

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

cross mob
lock attach
Attachments are accessible only for community members.
Not applicable
Hello everyone,

I need 6 GPIO interrupts and I am trying to use the ERU. I am using a Relax Kit with an XMC4500 F100K1024 AC chip.

I've set up IO002, ERU001, ERU002, and NVIC002 apps.

The ERU001 apps are set to the correct Event Request selection (Either signal A or signal B, depending on the input pin), and set to trigger both falling and rising edge with sticky flag enabled. I reset the flag in the interrupt handler.

So far I've tested pins 1.15, 0.9, 0.0, and 2.1.
1.15 and 0.9 work. 0.0 and 2.1 do not work.

Can anybody reproduce that? Is there a list of GPIO Pins that actually work with the ERU, contrary to what DAVE lets me configure and what the Reference Manual says?

I have attached a full demonstration project. Note that IO002 apps are set to (inverted) tristate. Setting a pulldown / pullup seems to prevent the ERU trigger from working.
6 Replies
Not applicable

I make a test on your project and added P0.0 for the ERU interrupt trigger.
For P0.0, it is working fine.
However, I also added P2.1 to test it and it doesn't seems to trigger the interrupt.
I will further checking on this issue and will update here if I get any findings.
10 replies posted 5 replies posted Welcome!
After reset P2.1 is configured as DB.TDO - you may have to change the configuration of the P2_HWSEL.HW1 bit field to 0b00 to change it to normal port operation.
The same should apply to P0.7 and P0.8, configured as DB.TDI and DB.TRST# respectively.
The Package Pin Mapping table in Data Sheet and Reference Manual mentions the special configurations of those ports pins after reset.
Not applicable
Ahh, that had not been on my radar at all. I thought DAVE would take care of things like that. I'll look into this, many thanks!
Not applicable
I am now trying to disable the DB.TRST function on Pin P0.8 to turn off the weak pulldown that the DB peripheral keeps on P0.8. To make sure I don't accidentally screw something up that makes the device undebuggable, I am doing this in a timer 2 seconds after reset.

#define MAINTIMER_PERIOD (100)
void main_timer() {
if (uart_state == BTActive) {
uart_state = BTPending;

if (trst_disabled < 20) {
} else if (trst_disabled == 20) {
// Disable DB peripheral's access to TRST
volatile uint32_t *port0_hwsel = (uint32_t*)(PORT0_BASE + 0x0074);
*port0_hwsel = 0x00004000;
trst_disabled = 255;
eru_pending = 1;

elmo_task_pending = 1;
can_send_pending = 1;
update_display = 1;

int main(void) {
handle_t systimer = SYSTM001_CreateTimer(MAINTIMER_PERIOD,
SYSTM001_PERIODIC, main_timer, NULL );
if (systimer) {

Memory watch shows me that after the register write executes, the port0 hwsel register has the correct value (0x00004000), but the pin is still fluttering until I pull it to GND for the first time. Am I writing the correct register bits? Do I have to do anything else to make sure the DB peripheral is disconnected from the TRST pin?

EDIT: I have just realised that Dave already configures the P0.8 HWSEL in DAVE_MUX_PreInit:

void DAVE_MUX_PreInit(void)
/* PORT Macro definitions for IOCR_OE, IOCR_PCR & HWSEL_HW */


And what it does is to enable the EBU.D6 function. In my application, I want to use the SDMMC, CAN, SPI, USIC and ERU peripherals, plus some bitbanged IO (using IO004) to drive a character display. Is there any reason for DAVE to set EBU.D6 function on P0.8 for any of these?
First solution authored Welcome! 500 replies posted
Not applicable
Thank you for the reply, but I'm afraid I'm past the point where this would be helpful. I have a working ERU setup, my problem right now is that setting the P0.8 HWSEL to software control doesn't work and the pin remains connected to EBU.D6. I would really like to make this pin work so I don't have to change my layout again.