Cannot see GPIO registers in MCUXpresso IDE

[vladimirilyenko]

Hi, trying to debug project on LPCXpresso54608 Dev. board (LPC54608J512ET180 MCU from NXP) and cannot see GPIO registers. I want to see the content of all the ports and pins of GPIO, but in the "Registers view" I see only Registers r0 - r12, sp, lr. pc and so on... (see the pictures). Cannot see GPIO here.

I see GPIO only in "Peripherals", but when I try to check this option here I get always "Remote communications error" and then "No registers found for GPIO". Then MCUXpresso IDE stops working and doesn't see target anymore. I need to reconnect dev.board again and restart MCUXpresso.

All other options under "Peripherals" are working - e.g. "ADC", "LCD" and "IOCON".

How can I see the content of GPIO registers in MCUXpresso?

[lpcxpresso_supp]

We have now managed to replicate this problem -  it appears to be related to the SDK version installed. We will now investigate further, and report back once we know more.

Regards,

MCUXpresso IDE Support

[lpcxpresso_supp]

Aside : MCUXpresso IDE v10.1 User Guide, section 10.6, "Peripherals" gives information on using the IDE's Peripheral View.

Anyway, we are not seeing any issues here viewing the LPC54608's GPIO registers (tested using the GPIO Led_output driver example under MCUXpresso IDE v10.1.1). As already stated by other, peripherals do have to be enabled and clocked to show registers/values - but failure to do so should not cause the problems you are seeing.

Can you confirm what version  of MCUXpresso IDE you are using, along with the SDK version you have? Along with details of the host OS you are running the IDE on and the debug connection type being used.

Can you also ZIP up and provide the .log file from the .metadata folder inside your workspace (from after you try and fail to display the GPIO peripheral).

Regards,

MCUXpresso IDE Support

[vladimirilyenko]

Hi, I have tried it again with the SDK Sample "lpcxpresso54608_driver_examples_gpio_gpio_led_output" and have the same result - errors.

The Version of MCUXpresso IDE I'm trying it with is: MCUXpresso IDE v10.1.1 [Build 606] [2018-01-02]   

SDK Version is: 2.3.0

Host OS is: Windows 7 Professional SP1 64-bit.

After trying to look at GPIO in Peripherals View I've made screenshots of error messages.

I attach here these screenshots along with the ZIPed .log file from the .metadata folder from workspace.

Crash message says: "crt_emu_cm_redlink.exe doesn't function anymor - close the program."

Hope it'll help to find the problem.

Regards,

[vladimirilyenko]

Well, I didn't get a thing...

I'll put the question another way:

How is it possible to see the content of GPIO registers in MCUXpresso?

I'm new in MCUXpresso. While using CodeWarrior one can see values of all the GPIO pins in Register View of every separate port, e.g. PORTA, PORTB, PORTC and so on. It was simple and reliable. 

If CodeWarrior would support LPC54608J512, I'd return to it.

I'm thinking about switching over to either IAR or Keil. 

MCUXpresso so far looks not matured enough.

[Catosh]

There are two points here: 
First one: if you don't clock the peripheral in your source code you will not able to access peripheral registers in MCU expresso, at least on the MCU I am working on now (LPC family). I learned this the hard way, and I suspect you are having a similar issue because of the "Remote communications error" you mention. OF course, it's just an hypothesis. 

Second one: even if clocked, neither I am able to see in detail the content of the gpio register, but I am not having the hard fault you mention. I took a look in the XML but everything seems correct there. No hint on this from my side. 
Hope NXP can provide some useful information. 
B.R.

L. T.

[vladimirilyenko]

Now I'm working with LPCXpresso54608 Developement board.

As far as I can see in fsl_gpio.c file the function CLOCK_EnableClock(s_gpioClockName[port]) is a part of function GPIO_PortInit(GPIO_Type *base, uint32_t port).

It should mean, that when the function GPIO_PortInit() for a certain "port" is called, the function CLOCK_EnableClock() for this "port" parameter should be automatically called also.

So why the function CLOCK_EnableClock() needs to be called separately again?   

Because initialization of GPIO with function GPIO_PortInit() is a must and is always done anyway.

Regards,

[Catosh]

Generally speaking before rendering a peripheral you have to turn it on, e.g. 
CLOCK_EnableClock(kCLOCK_Gpio0);

BTW, I am already enabling the clock of my gpio0 and have a similar issue..