Custom BSP and breakpoints don't work

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

Custom BSP and breakpoints don't work

1,936 Views
jerrystoner
Contributor III

I am using CW 10.3 with the appropriate MQX tools installed. I have a PEMicro Multilink Universal debugger. I have a custom board using a MK20DN512ZVLL10, running MQX 3.8.1. However, my BSP is from the K20D72M and I had to do some modifications to that BSP to account for differences in the MCG registers. I also changed the code to use the internal 8pf loading caps.


I had posted a question before, thought I figured it out but it turns out I didn't. I am trying a different approach now. My problem is that I can't actually seem to get breakpoints to work. First, if I set them they never actually trigger. Even if I set them in the cortex_boot.s file. I can step around just fine, just can't hit breakpoints. Second, if I set a breakpoint it doesn't do a single blue dot, it does a \ with a check mark. Hovering over it in the debugger view, it says "Multiple markers at this line" and lists the same breakpoint twice. They're address breakpoints FWIW.


I can't help but think these problems are related. The same debugger runs the same code (with a different BSP obviously) just fine on a twrk20d72m demo board and everything debugs normally.

0 Kudos
14 Replies

1,244 Views
Luis_Garabo
NXP TechSupport
NXP TechSupport

Hi Jerry,

I am sorry that you are facing these issues. First at all I want to clarify that MQX is not supported in CodeWarrior 10.3. I am not sure if this is the cause of the issue.

I suggest trying your code but under CodeWarrior 10.2. MQX was tested on this version and shouldn’t present any problem.

I hope this helps.

Have a nice day

-Garabo

1,244 Views
jerrystoner
Contributor III

Garabo,

After procrastinating on your suggestion in the hope of getting to use 10.3 still, I tried 10.2 and what do you know, the debugger works again. I am still having clock issues, but I think that's my code and not some IDE/debugger issue.

So now my question is why did everything work just fine using a more or less stock k20d72m BSP on the tower board with 10.3, but switching to the k20dn512z break the debugger?

Thanks again!

Jerry

0 Kudos

1,244 Views
c0170
Senior Contributor III

Hello Jerry Stoner,

Although I am not able to provide you an useful answer to your question, I just want to point out that this is CW related question and you might receive a helpful answer in CodeWarrior section here in our community.

Regards,

MartinK

0 Kudos

1,244 Views
Ali2006
Contributor II

Not sure if this is the answer or not.. but.. Did you change the .mem file to have the flash/code ranges for your chip since they are different from the K20d70 that you started with..

With that said..

since you have already done what I am struggling through and possibly others.. I was hoping maybe you could provide more details on how you managed to get the K20D72 to migrate to the K20DN512..    I've currently got an application compiling and downloading to my customer board.. but when I go to run it with the debugger  it just goes to __boot_exception.. and then to somwhere in the cortex_boot.s file.. and then back again..    I'm using MQX - 3.8.1 as well.. though I only have CodeWarrior 10.2    Almost seems like the debugger is trying to start at address 0-xFFFFFFFC.. as that is the first thing in the Thread List.. but I'm not sure (and that address shouldn't exist in my processor anyway) .. I have one application running under MQX on a custom board.. but it was a K70.. and I started with the K70Twr.. so it seemed to work a little easier I also tried the new BSP cloning software for the MQX 4.0 installation, but it didn't seem to make any difference.. I will still have to go through all the steps of figuring out what's wrong between the K20D72 and my K20DN512.     Does anyone know of any app notes that "detail" all the things that you need to change/fix/lookat when you are going from one proecssor to another in a BSP port.....

Thanks for your thoughts...

0 Kudos

1,244 Views
jerrystoner
Contributor III

Ali, thanks for your response. This is driving me nuts!

I have changed the .mem file to a file I found in C:\Freescale\CW MCU v10.3\MCU\ARM_EABI_Support\Memory_Config_Files. It seems to be alright. I thought there might be some issue with the lcf file too, but I modified one to correctly account for flash space and that at least lets me flash and verify :smileyhappy:

What's even more annoying is I tried one of my stock twrk20d72m projects again and it's doing this "multiple markers on this line" thing too.

0 Kudos

1,244 Views
Ali2006
Contributor II

Checking my code as well.. even though I know it doesn't load properly, I get the  multiple markers on this line error as well if I try to set a breakpoint here,  Maybe it's a clue.. :smileyhappy:   Does your code go to Main() after you download..


0 Kudos

1,244 Views
Ali2006
Contributor II

OK.. Based upon an SR request to Freecsale they say we can't use the K20D72 as a starting point.. So I went through the entire process of re-porting my system from the twrk40x256..  But I'm still at the same point.. So now I've tried harder to start my debugging and I find that I get through some of the MQX init code and then it seems I jump to never never land.. which gives me the boot exception.. Must be an interrupt I'm not handeling or something.. Before you try to re-port.. you might want to  Try Resetting your process.. but NOT run out of reset.. then single step through the code until you find out how far you can get.  chances are you are bombing in the MQX init stuff which is why it looks like you can't get to your breakpoints in your code.

FYI.. The re-port using the twrk40x256 wasn't too bad.. except be careful if you are renaming things.. you will rename a reference in the BSP .project file to a file in the MQX/SOURCE/IO/LCD directory that will then not be valid.  Choices are to NOT rename things.. or to just copy the offending lcd_twrk40x256.XXX files to your new name.. (Kinda Annoying)..

I also had to exclude some init_hmi file from the build as I wiped out the twr specific BSP PORT defines with my own..

Thanks.


1,244 Views
jerrystoner
Contributor III

Did this fix your "multiple markers" problem as well? I'm about to start the K40 port right now so we'll see how that goes!

0 Kudos

1,244 Views
Ali2006
Contributor II

Seems to be the case.. I don't see those multiple markers anymore and I'm hitting lots of breakpoint.. although I've not made it out of the MQX initialization code yet..

Has anyone ever had the system debugger walk you through GREYED OUT CODE.. .. Seems the IDE things it should be inactive.. but the program is actually going right throuh it.. I setup my clocks using code from the PE replacing the stuff in the bsp_cm.c initial setups.. but then later on in the code it starts going through the  Cpu_SetClockConfiguration and starts to change things again..


0 Kudos

1,244 Views
jerrystoner
Contributor III

Ali, that happens quite frequently. Unfortunately the communication between the programming and debugging view doesn't seem to work right. The programming view will correctly (most of the time, but not all) figure out what defines are present and what aren't and show the right sections. The debugger view can't seem to handle this for any code outside the project you're debugging. Since the MQX stuff is all in PSP and BSP, well, it has no clue.

I'm still working through porting the new BSP. Hopefully it works! Good to hear about the breakpoints!

0 Kudos

1,244 Views
Ali2006
Contributor II

Hi Jerry,

Have you made any major breakthroughs?

I find that I can set some basic IO ports on and off.. but I'm trying to use the UART specifically UART4 as the default

IO channel.. and I can't get anything to come out of it... and I still drop off to never never land if I just let my program run.

It's weird on the UART.. I can watch the code say that it's putting a value into the correct uart registers .. but the data never goes there.  The uart register does not change.  


0 Kudos

1,244 Views
jerrystoner
Contributor III

Ali,

Yes I have made some progress but it's too early to tell if everything is fixed. I had messed up my external oscillator so after I ditched the external 16MHz with PLL and just use the internal 32khz with the FLL boosted up. This solves any of the jumping-into-lala-land problems where my clock was dropping out and the clock monitor was resetting me.

I still have an issue where the first time I pause the code it stops at this one ASM label (_task_block). I can't step out of it and there's no breakpoint. I can only hit play or stop. But other than that my code seems to start and run properly.

I think I am also seeing your issue where things appear to be set up properly but nothing ever gets sent out. Going to work on testing that now and see if I can't find an answer.

0 Kudos

1,244 Views
Ali2006
Contributor II

I may have that answer for you..

In my system the

The init_gpio.c file   - function  bsp_serial_io_init is probably not using the correct pins.

I didn't carefully check UARTS0-3.. just my desired 4 & 5 and they were both not what I wanted.


0 Kudos

1,244 Views
jerrystoner
Contributor III

Ali,

Yes, that did help. I double checked all the IO I was using and did have to modify a few things. Mostly the UART. So far this all seems to be working pretty well. I am getting IO out and my processor seems to be stable.

0 Kudos