Editing __pe_initialize_hardware() in MQX

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

Editing __pe_initialize_hardware() in MQX

1,207 Views
mike65535
Contributor II

I'm trying to control (bit-bang) a pin (port A, pin 25, make it GPIO, make it output, make it HIGH) on a K61 device in the earliest stages of processor boot.

I am using MQX for an OS, building in IAR (all fully updated)

The right place for the code appears to be in bsp_cm.c, at the top of __pe_initialize_hardware().

However, when I try to add ANY code to that function - code to perform my bit-banging - although I can get it to build and download, I cannot get the code to run very far.  Using "Run to main" simply never stops at main.  Clicking the "red hand" causes the IDE to basically crash.

Setting a (earlier) breakpoint at (or performing a "Run to")  the top of __pe_initialize_hardware "works" - I mean it runs to and stops there successfully -  but at that point I cannot perform a go or stepover or stepinto (it gets lost just like before) . In addition, the assembly code looks like total gibberish - nothing like it looks when I don't add my bit-banging code.

Here's the one line of code I can add that causes it to crash.

PORTA_PCR25 = PORT_PCR_MUX(0x01);

Labels (1)
6 Replies

891 Views
mike65535
Contributor II

Thanks, that "hard fault" you indicated gave me hope, considering IAR totally crashes if I try to run my code but... that didn't solve the problem...

The equivalent of that line of code was already in the function __pe_initialize_hardware() ( in bsp_cm.c)

/* System clock initialization */

  /* SIM_SCGC5: PORTE=1,PORTC=1,PORTA=1 */

  SIM_SCGC5 |= (uint32_t)0x2A00UL;     /* Enable clock gate for ports to enable pin routing */

As you can see, portA is enabled. My code used to be BEFORE that line, so, I moved my code to below all that, but no avail.

As I see it, the fact that IAR shows me bogus assembly even BEFORE I step through my new code should tell us something (but I don't know what).

In other words, simply compiling in some code that (potentially) talks to the port causes the assembly view to puke even though I've set a breakpoint before even actually running that code.

Does that makes sense?

0 Kudos
Reply

891 Views
tom_thompson
Contributor III

Try the following code to enable the clocks:

SIM_SCGC5 |= SIM_SCGC5_PORTE_MASK | SIM_SCGC5_PORTC_MASK | SIM_SCGC5_PORTA_MASK;  // Enable clocks

These symbols are defined by the part-specific header file, MKL25Z4.h, if you are using the Freedom board.

---Tom

891 Views
mike65535
Contributor II

Interesting and confusing...

Somehwat by accident, I also ORed a ONE into bit 5 (the TSI bit)  with  this code

SIM_SCGC5 |= (uint32_t)0x2A20UL

and now it works, though I'm not happy to say it...

0 Kudos
Reply

891 Views
JimDon
Senior Contributor III

Well, at least for now it is working.

I am sure at some point it will dawn on you why!

0 Kudos
Reply

891 Views
mike65535
Contributor II

Well, as I add another line of code, it breaks again.

I don't know how adding a line of code can cause the entire Assembly view to show garbage.

0 Kudos
Reply

891 Views
JimDon
Senior Contributor III

Did you do this before writing the PCR register?

// Enable clock gate the porta

SIM_SCGC5 |= SIM_SCGC5_PORTA_MASK;

If not it will cause a hard fault.