Jump to content
43oh

and again weird errors - Keil uVision


Recommended Posts

I don't know what I've done but toolchains like to bite me... ;(

 

I'm trying to port an Arduino sketch to Tiva using Keil.

 

main.c

/*
 * Name RC522DumpMifare.ino
 *
 * 2013-07-xx started
 * 2013-08-03 first commit
 * 2013-08-08 anticol/select 7byte UID, RATS
 *
 * Based on code by www.electrodragon.com
 * and modified/fixed by http://twitter.com/regnerischerTag
 *
 * TODO: 
 *  - ISO/IEC 14443-4
 *  - Auth 7byte
 *  
 *
 
 
 *
 * ported to Keil for Stellaris/Tiva Launchpads
 * Stephan Goldenberg
 * 2014-06-01
 *
 */


#include "tm4c123gh6pm.h"	// TM4C123G Launchpad
#include "MFRC522.h"		// symbols for RC522 by regnerischerTag

// using SSI0 [PA_5 - MOSI, PA_4 - MISO, PA_3 - CS, PA_2 - SCK], PA_6 - CS, PA_7 - NRSTPD
// using UART0 PA_0 & PA_1 for serial communication

#define chipSelectPin 0x40
#define NRSTPD 0x80

#define	uchar	unsigned char
#define	uint	unsigned int
//data array maxium length
#define MAX_LEN 16

SYSCTL_RCGC1_R |= SYSCTL_RCGC1_SSI0;	// activate clock for SSI0 *
SYSCTL_RCGC2_R |= SYSCTL_RCGC2_GPIOA;   // activate clock for port A *
unsigned int tictac = SYSCTL_RCGC2_R;   // waste some time for the oscillator to settle *
GPIO_PORTA_PCTL_R = (GPIO_PORTA_PCTL_R&0xFF0F00FF) + 0x00202200; *
GPIO_PORTA_AMSEL_R = 0;			// disable analog modules *
GPIO_PORTA_AFSEL_R |= 0x34;		// enable alt function on PA2,4,5 *
GPIO_PORTA_DIR_R |= 0x08;		// disable PA3 (CS) - done using regular GPIO *
GPIO_PORTA_DEN_R |= 0x3C;		// enable digital IO on PA2,3,4,5 *
GPIO_PORTA_DATA_R |= 0x08;		// pull PA3 high

SSI0_CR1_R &= ~SSI_CR1_SSE;		// disable SSI0
SSI0_CR1_R &= ~SSI_CR1_MS;		// master mode
SSI0_CPSR_R = (SSI0_CPSR_R&~SSI_CPSR_CPSDVSR_M)+4;// clock perscaler for 1.5MHz SSIClk
SSI0_CR0_R &= ~(SSI_CR0_SCR_M | SSI-_CR0_SPH | SSI0_CR0_SPO);
SSI0_CR0_R = (SSI0_CR0_R&~SSI_CR0_FRF_M)+SSI_CR0_FRF_MOTO;// Freescale mode
SSI0_CR0_R = (SSI0_CR0_R&~SSI_CR0_DSS_M)+SSI_CR0_DSS_8;	// 8-bit data
SSI0_CR1_R |= SSI_CR1_SSE;		// enable SSI

SYSCTL_RCGC1_R |= 0x0001;		// activate UART0
SYSCTL_RCGC2_R |= 0x0001;		// activate port A
UART0_CTL_R &= ~0001;			// disable UART0
UART0_IBRD_R = 43;			// IBRD = (80M / (16 * 115k2)) = int(43.40278)
UART0_FBRD_R = 26;			// FBRD = round(0.40278 * 64) = 26
UART0_LCRH_R = 0x0070;			// 8-bit word length, enable FIFO
UART0_CTL_R = 0x0301;			// enable RXE, TXE and UART
GPIO_PORTA_PCTL_R |= (GPIO_PORTA_PCTL_R&0xFFFFFF00) + 0x00000011;


void digitalWrite(int pin, bool state){
	if(state){
		GPIO_PORTA_DATA_R |= pin;
	} else{
		GPIO_PORTA_DATA_R &= ~pin;
	}
}

unsigned char SPI_transfer(unsigned char data){
	unsigned short rec_data;
	
	GPIO_PORTA_DATA_R &= ~chipSelectPin;	// !CS = 0
	sendAfterWaiting(data);			// send command
	rec_data = sendAfterWaiting(0);		// send nothing, receive byte
	GPIO_PORTA_DATA_R |= chipSelectPin;	// !CS = 1
	return rec_data;
}

unsigned char sendAfterWaiting(unsigned char code){
	while((SSI0_SR_R&SSI_SR_TFE) == 0){};	// wait until FIFO empty
	SSI0_DR_R = code;			// push data out
	while((SSI0_SR_R&SSI_SR_RNE) == 0){};	// wait for response
	return SSI0_DR_R;
}

At the lines marked with a '*' at the end Keil shows: "error: expected identifier or '('." except the tictac line where it says: "error: initializer element is not a compile-time constant".  Can someone tell me why ? I don't get it.

 

 

post-3-14264605415886_thumb.png

post-3-14264605416638_thumb.png

Link to post
Share on other sites

Is the posted code complete? Certainly placing functional statements such assignments to SYSCTL_RCGC1_R at functionfile level is not valid C, so perhaps that's inside a code block that was removed (or was not added as it needs to be).

It's unusual in pre-C99 code to intersperse variable declarations like the one for tictac with code, so that warning may be a different issue.

Edited by pabigot
Link to post
Share on other sites

If the sole reason you're creating and assigning to tictac is to generate a delay to avoid a hw fault operating on the GPIO before the module warms up, then (1) see this and some related thread somewhere about how the NOP instruction might be spelled in energia, and (2) just move the enable of PORTA up and use the time it takes to enable SSI0 to generate the delay.

 

In straight-line code as you have it, it's nice to keep the internal order the same anyway: enable all the modules (PORTA, SSI0); configure all the modules (PORTA, SSI0). By following this practice you'll absorb the necessary module startup time doing useful things.

 

Also, it was unclear if you were just posting the final version or if you're still having a problem.

 

Finally, just FYI, I believe the RCGC1 and RCGC2 registers are deprecated in favor of peripheral-specific modules like RCGCGPIO and RCGCSSI which support more instances of each peripheral.

Link to post
Share on other sites

If the sole reason you're creating and assigning to tictac is to generate a delay to avoid a hw fault operating on the GPIO before the module warms up, then (1) see this and some related thread somewhere about how the NOP instruction might be spelled in energia, and (2) just move the enable of PORTA up and use the time it takes to enable SSI0 to generate the delay.

This delay is about the modules ? I thought it is for the XTAL and if you don't wait immediately the whole oscillator/PLL would lock up. There was one exercise where I forgot this dummy assignment and the grader complained the clock would not be running. But it's possible that the grader checked whether a dummy assignment exists. I have to admit I've never read the errata. (1) Was a good read, I wonder why opcodes like MOV r5,r5 do exist at all.

 

Also, it was unclear if you were just posting the final version or if you're still having a problem.

 

That was just to show the errors have gone. 'Ahh' is the german 'sigh of relief'. :) I have to implement wrappers for Serial.print/ln() and then paste in the Mifare handling code and replace all Arduino calls with wrapper calls...just about 900 lines of code. :blink:

 

Finally, just FYI, I believe the RCGC1 and RCGC2 registers are deprecated in favor of peripheral-specific modules like RCGCGPIO and RCGCSSI which support more instances of each peripheral.         

 

As usual, once you think you start to get it things are changing.

 

Busy day today, I started editing this at around 10am now it's 2:30pm.

 

Have fun,

Stephan

Link to post
Share on other sites

SystemInit is a CMSIS standard startup function normally implemented in the system_DEVICE.c file and referenced from startup_DEVICE.s. TivaWare doesn't use CMSIS, so that may explain why it can't be found: looks like you're using the standard Keil ARM infrastructure but it's not compatible with the device-specific material provided by TI.

 

Ignoring the specific application you want to get working, are you able to build and run a standalone blink-the-led application on your target hardware under Keil? If not, get that working first. If so, see what the difference is between that working program and this one.

 

You might find it easier to use gcc or Code Composer Studio to get a working application first, then try to port it to Keil.

Link to post
Share on other sites

I've expanded the search to "Undefined symbol SystemInit" and found I need to provide a void SystemInit(). I did so with PLL Init code. Now it builds but things are getting worse. The debugger shows errors:

*** error 65: access violation at 0x400FE070 : no 'write' permission
*** error 65: access violation at 0x400FE050 : no 'read' permission
*** error 65: access violation at 0x400FE050 : no 'read' permission
*** error 65: access violation at 0x400FE050 : no 'read' permission

I'll give CCSv6 a try now.

 

Thanks,

Stephan

Link to post
Share on other sites

I take this as a sign  :blink:

 

Update: Ah..for some reason a XDS100... JTAG was set && my SystemInit() "workaround" was still present. I have a running Tiva now. I get only garbage (prolly down to the 45 warnings :lol: ) but it runs. I'll take that to improve my debugging skills. Enough for today, F1 time now. Thanks and sleep well,

 

Stephan

post-3-14264605417684_thumb.png

Link to post
Share on other sites

There is no SPI action. SSI_DR_DATA does never change, even writing to it has no effect. I've been looking at the registers and even after

	SSI0_DR_R = code;   //code = 0x02 at the moment

it does not change. How's that ? When I step through the initialisation, I can see the status registers change. I've attached an cheap chinese clone logic analyzer and that shows action only on the regular GPIO lines, the SPI lines are dead. Well, if there is nothing to transmit...

 

Any ideas ?

post-3-14264605418582_thumb.png

Link to post
Share on other sites

Hmm, must get back to Arduino and stick with it, it seems.

 

Tried Energia with the Tiva - did not work. Dug out the Duemillanove and tried MPIDE - did not compile.

Installed Arduino IDE - does compile and upload and

Card detected.
 ATQA: 04 00  
 UID:  83 41 EB A4 
 SAK: 8
Sector 0: 
 83 41 EB A4 8D 08 04 00 62 63 64 65 66 67 68 69 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF 
Sector 1: 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
...

16 sectors read and displayed.  :unsure:

 

Edit: Just to rule out a broken Tiva, I've tried a Stellaris Launchpad with Energia. No SPI communication too, reading the version of the RC522 fails already. What's wrong with TI's SPI modules ?

 

And another edit: Got it to work with Energia, Stella & Tiva. Energia's default for SPI is SSI2, I had SSI0 wired. Good news, the hardware is fine but what's the problem with CCS. If someone wants to have a deeper look: https://github.com/stehgold/rc522

Link to post
Share on other sites

Meh, progress but in baby steps. The main clock was off, I've configured the clock to run at 80MHz and the serial line to the PC is fine now. But still no SPI response. The logic analyzer shows some action on MOSI and SCK, clock rate seems to be at 4 MHz. The MFRC should be able to handle that but MISO stays HIGH forever.

 

 

post-3-14264605418956_thumb.png

Link to post
Share on other sites

OK, let me continue talking to myself im public...

 

Another baby step forward. The regular GPIO pins used weren't configured. Now I get comm via SPI but it's weird. According to the logic analyzer, MOSI is counting up from 0, MISO returns MOSI+1 (00->01, 01->02, 02->03, ...).

post-3-14264605420456_thumb.png

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...