No Freemaster connection with S32K148EVB-Q176

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

No Freemaster connection with S32K148EVB-Q176

3,953 Views
lawrence_minnet
Contributor I

Hi All,

I'm quite new to this all and tried to get my board up and running using a couple of different quick start guides and posts from this community. Unfortunately none of it has resolved my problem to connect in freemaster with the board described above.

I tried the following things:

- Installed FreeMaster v2 & v3

- Installed FreeMaster Communication Driver

- Installed Windows USB drivers from this website (PEmicro | Experts in Embedded tools for Flash Programming and Development )

- Updated MSD-Debug to v122 and OpenSDA to v108 using the bootloader mode on the target board

The way I'm trying right now is through the model based design toolbox by compiling simulink example models. I was able to flash a slightly modified LED example for the S32K148 board (I don't have stateflow) and added a Freemaster config block (attached images). When I open the board as a drive on my pc a .mot file shows up.

But when I run the connection wizard on FreeMaster it doesn't find the board. I have tried to follow some of the other guides, but had so far no luck. I followed this instructions as well https://community.nxp.com/thread/464233 , but I was not sure if it didn't work because I did something wrong or the difference in board won't make it work.

Either way, I'm somewhat out of ideas. Is it possible that one of the drivers wasn't installed properly? Is there a way to check?

Thanks for your help,

Lawrence

0 Kudos
15 Replies

3,305 Views
iulian_stan
NXP Employee
NXP Employee

Hi Lawrence,

My first guess would be to check the pin mapping for LPUART1 if you are using the serial communication over OpenSDA mini USB port. If it's indeed the case double check the pins. I would suggest trying PTC6 and PTC7 as per quick guide specifications.

Regards,

Iulian

0 Kudos

3,305 Views
lawrence_minnet
Contributor I

Hi Iulian,

thanks for your input. I am using the LPUART1 port with pins PTC6 & PTC7 assigned in the freemaster config block. I did however not try any other ones yet. 

I am able to run the debugger on S32DS with the simulink compiled project. Might be worth checking what’s actually sent out and on what pins. I’m not completely sure what function call that would be. 

Best, 

Lawrence

0 Kudos

3,305 Views
iulian_stan
NXP Employee
NXP Employee

FreeMASTER communication is always initiated by the PC host application. When you try to connect to the board it sends the "connect mesage" to the board, so the thing you could look for in debug mode is whether it hits FMSTR_Isr function (this should handle the UART interrupt). You can see the messages sent and received on PC side in the log window: Tools → Communication Debug Log ...

Untitled.png

I'm not familiar with Matlab toolbox, but if you are working with S32DS you can also try freemaster example projects available in the SDK. Select New S32DS Project from Example

Untitled.png

Capture.PNG

And compare the that configuration with the one generated by simulink.

Regards,

Iulian

0 Kudos

3,305 Views
lawrence_minnet
Contributor I

Hi Iulian,

I looked at the communication debug log and got the following messages (one on verbosity normal, the other on verbosity all).

pastedImage_1.png

pastedImage_2.png

I'm not sure if you can see something from this log.

I tried the example project you suggested as well, but wasn't able to communicate through Freemaster either. I can give it another try to see if it hits the function FMSTR_Isr  this time.

Thanks,

Lawrence

0 Kudos

3,305 Views
iulian_stan
NXP Employee
NXP Employee

Error code 0x80000101 (Response timeout) means the host applications never gets a reply from the target board, I would say that it never reaches the embedded application. But it's quite strange that neither the SDK example works. Could you share the .mot file, so I can ask someone from Matlab team to check it.

Iulian

0 Kudos

3,305 Views
lawrence_minnet
Contributor I

Hi Iulian,

Yes, I agree. I'm going to check the example from SDK, as I have spent less time with that. There should be a .mot file visible on the drive either way, right?

I attached the .mot file from simulink in the meantime.

Thanks,

Lawrence

0 Kudos

3,305 Views
iulian_stan
NXP Employee
NXP Employee

Hi Lawrence,

When flashing with DS you won't see a .mot file (the IDE can generate those files but by default flashes the application directly into the memory, when you copy a .mot file to the mounted drive a separate chip will load it).

I copied your file on a S32K148EVB-Q144 (revC) board (according to schematics there should not be critical differences between this one and your board) and it worked.

Other troubleshooting I can suggest:

  • Try a different USB port on the host PC
  • Flash a sample UART application to confirm the module works

You could also use a different UART module (in this case you would need to use a serial to USB converter)

Regards,

Iulian

0 Kudos

3,305 Views
lawrence_minnet
Contributor I

Hi Iulian,

I just tried different USB ports and none of them worked. Additionally as you suggested I tried the lpuart_echo demo for my board using putty to see if the communication works there.

pastedImage_1.png

I was able to receive a message on Putty that's sent out initially from the board. When I then step through the main loop, it runs through the     while(strReceived == false)     loop once and then gets stuck in the while loop I marked with the arrow. No matter what I input to the terminal.

So it seems at least the transmit part from the board seems to work, but maybe not the receive...?

I'll look for a serial to USB converter, but was hoping to get this to work without it.

Thanks,

Lawrence

0 Kudos

3,305 Views
iulian_stan
NXP Employee
NXP Employee

Hi Lawrence,

Check this regarding SDK UART demo app.

Not sure if putty can sent '\n' termination line. You could try Termite client.

Capture.PNG

Regards,

Iulian

0 Kudos

3,305 Views
lawrence_minnet
Contributor I

Hi Iulian,

Thanks for the hint. I tried it with Termite and it still doesn't work. I spent some more time debugging the code and I came across something that confuses me.

Since the code didn't behave as I expected I added a variable (debug), which I further use in the while statement. Now although the debug variable reads STATUS_BUSY the while loop is never executed.

I'm not sure if this might be part of the problem, but it's for sure an unexpected behavior to me.

pastedImage_1.png

0 Kudos

3,305 Views
iulian_stan
NXP Employee
NXP Employee

It's the semi-column after the while condition (remove it).

But if it still does not work I'm afraid it is more likely a hardware issue rather than software.

Regards,

Iulian

0 Kudos

3,305 Views
lawrence_minnet
Contributor I

You're right. That solved that while loop.

But as you probably expected that didn't solve the problem.

I guess it has to be hardware related or something to do with the UART driver. Did you say you tried it with the same board? I'm curious because I'm trying to evaluate if I need to switch to a different one if the problem persists as eventually we're going to need a couple of them.

Thanks for your continued help,

Lawrence

0 Kudos

3,305 Views
iulian_stan
NXP Employee
NXP Employee

Hi Lawrence,

Yes, I tried those examples on an older version of the same board S32K148EVB - Q144 (revision C). In all cases I was using LPUART1 with PCT6 and PTC7, as I understood it's the only configuration allowing communication over the mini USB port. I checked with my colleagues who have more hardware expertise and concluded that it should not affect the functionality of the examples not on Q144 nor Q178.

There were also similar cases (factory defects) when one of the serial lines was damaged (either on the processor pin level or the route to the pin). But these can be confirmed by trying different configurations directly connecting to the pinout and analyzing the signal.

Capture.PNG

Regards,

Iulian

0 Kudos

3,305 Views
lawrence_minnet
Contributor I

Hi Iulian,

I checked the pins and I saw a signal on the Rx pin while trying to set up the connection, but nothing on the Tx pin. The one UART example we talked about above however had something sent out on the Tx pin (which is why I got the initial message in the example). I'm therefore not sure if the pin of the Rx is faulty on the processor or something else is going on...

I just realized that I can connect to freemaster using the plug-in module instead of the RS232. Is there any difference in using one over the other?

Thanks,

Lawrence

0 Kudos

3,305 Views
iulian_stan
NXP Employee
NXP Employee

Hi Lawrence,

Communication plugins are dynamically-loaded libraries that allow FreeMASTER host application to connect to the board using additional physical interfaces beside UART such as CAN, BDM or JTAG. It will also require corresponding changes on the embedded side. Please refer to the User Guide for more information.

Untitled.png

You can also go to the What's New page from the Welcome screen directly inside the FreeMASTER tool.

Capture4.PNG

Just click on the (more...) link to to see the list of supported probes and a short usage description:

Capture5.PNG

Those cover only the host side, for the embedded side, check the Communication Driver User Guide. Note that the online documentation available on the FreeMASTER download page targets latest version of the communication driver the examples from S32DS and Mtalab Toolbox use the previous one (latest host tool is fully backward compatible), so you need to refer to the one from the previous package:

Capture6.PNG  

That one one contains also contains ready to use examples that you could use as reference:

Capture8.PNG

Capture7.PNG

Regards,

Iulian

0 Kudos