LPC17xx interrupts

[YahooArchive]

> They do compile with the *'s removed, however, I can't say whether or not it
works because TIMER1_ISR is not defined. (The string "_ISR" does not occur
anywhere in LPC17xx.bas.)

The vector ISRs have to be added to LPC17xx.bas

In C they are defined in crt0.S and are the low 40 words of memory. While it
looks like its in Flash that space is actually overlaid by psuedo-registers so
it is writable.

TIMER1_ISR whether it keeps that name would be at 18*4

[YahooArchive]

I tried:

#define TIMER1_ISR *(18 * 4)

and

#define TIMER1_ISR *(&H18 * 4)

Either causes:

FaultISR 0xFFFFFFF9
Imprecise data bus error

when TIMER1_ISR is assigned.

Please let me know when you have updated Basic Tools on your website.

-MM

[YahooArchive]

> when TIMER1_ISR is assigned.
>

Depending on which ARM and how the interrupts are remapped, for the SuperPRO the
remap is into RAM so that address should have started at &H10000000

I dug back through the archives and found the definitions for those vectors and
posted them below, the LPC17xx.bas file will be updated.

> Also it seems that when code size exceeds about 9.25 K, the program fails to
start automatically on reset? Is that a limit of BASIC?
>

The test programs we normally use for the BASIC compiler are limited to 20K so
they fit in the LPC2103, and they run fine on the SuperPRO (at around 18K, the
code is a little smaller when in thumb mode)

We have tested special cases of very long FOR loops up to 64K.

There is a limit in the current compiler of 128K of code space.


vector ISR locations --

'VIC Vector Table
#define PSV_ISR *&H10000038 ' 14: The PendSV handler
#define SYSTICK_ISR *&H1000003C ' 15: The SysTick handler
#define WDT_ISR *&H10000040 ' 16: Watchdog Timer
#define TIMER0_ISR *&H10000044 ' 17: Timer0
#define TIMER1_ISR *&H10000048 ' 18: Timer1
#define TIMER2_ISR *&H1000004C ' 19: Timer2
#define TIMER3_ISR *&H10000050 ' 20: Timer3
#define UART0_ISR *&H10000054 ' 21: UART0
#define UART1_ISR *&H10000058 ' 22: UART1
#define UART2_ISR *&H1000005C ' 23: UART2
#define UART3_ISR *&H10000060 ' 24: UART3
#define PWM1_ISR *&H10000064 ' 25: PWM1
#define I2C0_ISR *&H10000068 ' 26: I2C0
#define I2C1_ISR *&H1000006C ' 27: I2C1
#define I2C2_ISR *&H10000070 ' 28: I2C2
#define SPI_ISR *&H10000074 ' 29: SPI
#define SSP0_ISR *&H10000078 ' 30: SSP0
#define SSP1_ISR *&H1000007C ' 31: SSP1
#define PLL0L_ISR *&H10000080 ' 32: PLL0 Lock (Main PLL)
#define RTC_ISR *&H10000084 ' 33: Real Time Clock
#define EINT0_ISR *&H10000088 ' 34: External Interrupt 0
#define EINT1_ISR *&H1000008C ' 35: External Interrupt 1
#define EINT2_ISR *&H10000090 ' 36: External Interrupt 2
#define EINT3_ISR *&H10000094 ' 37: External Interrupt 3
#define ADC_ISR *&H10000098 ' 38: A/D Converter
#define BOD_ISR *&H1000009C ' 39: Brown-Out Detect
#define USB_ISR *&H100000A0 ' 40: USB
#define CAN_ISR *&H100000A4 ' 41: CAN
#define DMA_ISR *&H100000A8 ' 42: General Purpose DMA
#define I2S_ISR *&H100000AC ' 43: I2S
#define ETH_ISR *&H100000B0 ' 44: Ethernet
#define RIT_ISR *&H100000B4 ' 45: Repetitive Interrupt Timer
#define MOTOCON_ISR *&H100000B8 ' 46: Motor Control PWM
#define QUAD_ISR *&H100000BC ' 47: Quadrature Encoder Interface
#define PLL1L_ISR *&H100000C0 ' 48: PLL1 Lock (USB PLL)

[YahooArchive]

It doesn't error any more but the interrupt routine never gets called, this is
what I have (copied from the example):

SUB ON_TIMER (msec, isr)
TIMER1_ISR = isr ' or 1 'set function of VIC
VICIntEnable = VICIntEnable or (1<<2) 'Enable interrupt
T1_MR0 = msec-1 ' set up match number of ms
T1_MCR = 3 ' Interrupt and Reset on MR0
T1_IR = 1 ' clear interrupt
T1_TC = 0 ' clear timer counter
T1_TCR = 1 ' TIMER1 Enable
ENDSUB


And ther call to set it:


ON_TIMER(250, ADDRESSOF TIMER1IRQ)


-MM

[YahooArchive]

> TIMER1_ISR = isr ' or 1 'set function of VIC


If this is what you typed, then that would be wrong

The or 1 is important ( + 1 ) would also work
Your ' would comment that out

This is a Thumb instruction ARM and the 1 indicates Thumb mode, it does
unpredictable things when not set.

PS By just cutting and pasting what I posted into the example worked and I was
getting . on the screen every 2 seconds.

[YahooArchive]

>
> > TIMER1_ISR = isr ' or 1 'set function of VIC
>
>
> If this is what you typed, then that would be wrong
>
> The or 1 is important ( + 1 ) would also work
> Your ' would comment that out

My bad, I tried it as it was first, and then took a stab in the dark, thinking
it might've been a throw-back to something else.


> This is a Thumb instruction ARM and the 1 indicates Thumb mode, it does
unpredictable things when not set.
>
> PS By just cutting and pasting what I posted into the example worked and I was
getting . on the screen every 2 seconds.
>

Actually not quite, you would've had to remove the asterisks from the lvalues in
ON_TIMER, otherwise it wouldn't have compiled.

The problem in my code was this line:

' this does not work
VICIntEnable = VICIntEnable or (1<<2) 'Enable interrupt

' this works
VICIntEnable = *VICIntEnable or (1<<2) 'Enable interrupt

I found this completely by accident, after editing TIMER1.bas to make it
compile, but forgetting to remove the asterisk from *VICIntEnable where used as
an rvalue.


Now if I could figure out my bootstrap problem I'd be out of your hair. Is it
possibly caused by multiple SUBs/FUNCTIONs that DIM a variable with the same
name?

I added extra size to all my strings and integer arrays, thinking maybe I had
some one-off out-of-bounds array access, or string overflow going on, but no
love. Apparently it's not directly connected with code size, as now it's
happening with 8.87K of code.

Any clues as to what sort of code problem might possibly cause the board to fail
to run its program on reset would be appreciated.


-MM

[YahooArchive]

> Now if I could figure out my bootstrap problem I'd be out of your hair. Is it
possibly caused by multiple SUBs/FUNCTIONs that DIM a variable with the same
name?
>

Most likely the check for a BASIC program in firmware is too simplistic. This
means in the long run we'll have to change it, but we can patch it in the
compiler.

However, the quick fix for you would be to move your main: so it is much closer
to the start of the code.

Look at what code is at the start

@10000

And if 10003 == FF the code will not start.

[YahooArchive]

>
> > Now if I could figure out my bootstrap problem I'd be out of your hair. Is
it possibly caused by multiple SUBs/FUNCTIONs that DIM a variable with the same
name?
> >
>
> Most likely the check for a BASIC program in firmware is too simplistic. This
means in the long run we'll have to change it, but we can patch it in the
compiler.
>
> However, the quick fix for you would be to move your main: so it is much
closer to the start of the code.

Shezam! That did it. GOSUB being able to forward-reference labels made it easy
to rearrange code I had originally placed in conventional procedures... the code
reads about the same.

Thanks!


-MM