Communication error while accessing MDM-AP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Communication error while accessing MDM-AP

Jump to solution
6,708 Views
samdexter
Contributor II

It worked fine just yesterday but today I've got this:

Kinetis (connect): Communication error while accessing MDM-AP...

MKM34Z256VLL7 with j-link on Kinetis Design Studio v.3.2.0.

Searching Internet did not bring any insight into what could cause the issue and

what to do about it. The bottom line is - I cannot program my board anymore...

Did anybody have a similar issue? Any ideas are welcomed.

Thank you very much.

1 Solution
5,070 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Sam,

    Because the internal pulled up is weak, then we recommend the customer add the external pull up resistor in NMI, reset pin.

   Is your debug issue now only happen in converting the tower project?

   Did you try to create a new project, eg, just a very simple KDS project, and then download it to your own board, whether that can be ok or not?

   From your debug log, I find you already enter the debug mode, and the code is running, it should caused by the code.

For example, the code have some error which cased by the mismatch between your own board and the tower board.

   Did you use the same external clock circuit as the tower board? If not, it maybe caused by the clock system. Please check your clock system configuration.

Wish it helps you!

Have a great day,
Kerry

 

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
---------------------------------------------------------------------------------------------------------------------

View solution in original post

8 Replies
5,070 Views
samdexter
Contributor II

Unbelievable...

It happened again on another, brand new board...

0 Kudos
5,070 Views
MarMi
NXP Employee
NXP Employee

Hello Sam,

I took new TWR-KM34Z75M from box and tried to flash lcd_test_twr_km34 example using:

1) PEMicro OpenSDA (USB cable plugged into J27)

2) Segger J-link (USB cable plugged into J27 + J-link debug probe plugged into J24)

In both cases software was downloaded and executed properly. Only issue I saw was using option 1 while leaving J-link debug probe still plugged into J24 - in this case P&E connection assistant has shown up and J-link debug probe has to be unplugged in order to be able to continue with software upload.

Can you please try using lcd_test_twr_km34 project (attached) along with lcd_test_twr_km34_Debug_PNE debug configuration?

Kind regards,

Martin M. 

0 Kudos
5,070 Views
samdexter
Contributor II

Thank you Martin.

Yeah, failed to mention - I am working with my own boards...

After poking around for a bit I found that connecting the reset

pin to the debugger solved the problem. To my knowledge

SWD does not require the reset pin to be connected but,

perhaps, it has something to do with the debugger.

Best Regards,

Sam.

0 Kudos
5,070 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Sam Dexter,

    When you didn't connect the reset pin to the JLINK, did you add the 4.7K to 10K external pull up resistor in the Reset_b pin, and connect a 0.1uf capacitor between reset and the ground?

   NMI also need an external 4.7K to 10K pullup resistor.

   Normally,  even without the reset pin connection to the SWD, the chip also can be programmed with the command reset from the debugger if your chip's external circuit is correct.

  But to stable program, it is better to add the Reset_b pin to the debugger interface.

Wish it helps you!

Have a great day,
Kerry

 

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
---------------------------------------------------------------------------------------------------------------------

0 Kudos
5,070 Views
samdexter
Contributor II

OK, thank you Kerry...

According to the datasheet the reset pin is internally pulled up so - no, I didn't have external

components populated. Both boards seem to work fine now with the reset pin connected to

the debugger.

However, I've got another issue after converting a MKM34Z75 tower project over to my board -

Starting target CPU...
ERROR: Can not read register 15 (R15) while CPU is running
...Target halted (PC = 0x00000000)
Reading all registers
ERROR: Can not read register 0 (R0) while CPU is running, etc.

Populated the external reset circuitry but that made no difference. Any idea?

Regards,

Sam.

0 Kudos
5,071 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Sam,

    Because the internal pulled up is weak, then we recommend the customer add the external pull up resistor in NMI, reset pin.

   Is your debug issue now only happen in converting the tower project?

   Did you try to create a new project, eg, just a very simple KDS project, and then download it to your own board, whether that can be ok or not?

   From your debug log, I find you already enter the debug mode, and the code is running, it should caused by the code.

For example, the code have some error which cased by the mismatch between your own board and the tower board.

   Did you use the same external clock circuit as the tower board? If not, it maybe caused by the clock system. Please check your clock system configuration.

Wish it helps you!

Have a great day,
Kerry

 

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
---------------------------------------------------------------------------------------------------------------------

5,070 Views
samdexter
Contributor II

Every example project from KSDK-1.3.0 causes this problem, however,

none of the examples from KSDK-2.0...

Still trying to figure out the difference.

0 Kudos
5,070 Views
samdexter
Contributor II

Hi Kerry,

You were right. The problem was related to the clock configuration.

BOARD_InitRtcOsc(), to be specific.

Solved. Thank you very much.

Regards,

Sam.

0 Kudos