I-Appliance BBS
The Official Source for Internet Appliance Upgrades and Mods

Click Here!
BBS Main List | Sign In | Sign Up | Search | Help | Linux-Hacker.netReply to Thread | Printer |

Home / MISC Areas / Mattel JuiceBox
IRQ programming
IRQ programming

New MessageIRQ programming (modified 0 times) ForkBoy
Profile
As promised I've been working on trying to add IRQ support to unix_guy's terminal application.

Programming the IRQ interrupt requires me to write to address 0x18.

I have been able to write to this address and get a serial RX interrupt working, but the results are not consistent.

If I boot up the Juicebox with no cartridge and load my application to RAM using openocd, the address is usually not written to
the first time I run the application. The second time I run the application, the address is written to properly.
Changing the CPSR register to enable / disable IRQ interrupts has similar results.

Additionally, if I boot FatBox from external flash, the ARM always appears to be in User mode and I can't write to 0x18 or the CPSR register.

* Does anyone have any ideas why the JuiceBox behaves this way or how to change from User mode to another mode?

I'm thinking that the issues I'm encountering could be due to other pending interrupts, pipelining, or the processor mode.

I can be reached via e-mail at drareve at yahoo dot com to exchange code or ideas.

Once I can get past this hurdle we can start using the interrupts for fun things like the uart and timer. All useful information will be added to the Wiki.

01-11-2007 22:41:14

New MessageRE:IRQ programming (modified 0 times) jasonharper
Profile
Address 0x18 is in ROM, isn't it? You're perhaps succeeding in writing something into the cache with that address, but it's only going to stick around until other memory accesses push it out of the cache.

Hopefully 0x18 in ROM contains a jump to some address in RAM that you can freely write to. If not, consider using one of the BDMA channels to read the serial port - it looks like that would be a lot more work to set up, but would give you potentially much better performance than dealing with incoming characters one-by-one in an interrupt handler.

01-12-2007 10:57:23

New MessageRE:IRQ programming (modified 0 times) ForkBoy
Profile
jasonharper,

The S3C44B0X user manual specifies location 0x18 as residing in "SROM" meaning SRAM or ROM.
I thought I read some place that this is ROM for the Juicebox, confusing me as to why I could sometimes write to it.

When I disassembled the default memory, it looks like the IRQ ends up in the 0xC000000 range (not 0x0C00000) in an infinite loop.

Thanks for your suggestions, I'll look into the CACHE and BDMA and see if I come up with anything useful.

01-12-2007 11:45:29

New MessageRE:IRQ programming (modified 0 times) ForkBoy
Profile
jasonharper was correct, the cache was causing false writes to location 0x18.

When I disabled the cache with *SYSCFG &= (~0x00000006); things behaved as expected -- as ROM.

Additionally, I was incorrect with my initial assessment of where the interrupt was jumping. (Makes sense because 0x1000_0000 < 0xC000_0000)
My disassembler didn't have a leading 0 before the C (LDR PC, =0xC000018)

Which is

LDR PC, =0x0C000018

This resides in the happy ram land -- very promising indeed!

01-15-2007 22:16:50

New MessageRE:IRQ programming (modified 1 times) ForkBoy
Profile
IRQ success

I've had success and updated unix_guy's terminal application to support 115200 baud using the uart rx IRQ and a circular receive buffer.
The new serial application can be downloaded from the Wiki: http://www.elinux.org/wiki/JuiceBoxFAQHardThings

Here are the details:

When the JuiceBox boots FatBox, the CPSR register is 0x60000010 this means IRQ and FIQ interrupts are enabled -- no change to CPSR is needed

When an IRQ interrupt is called, the JuiceBox jumps to location 0x00000018

Location 0x00000018 contains LDR PC, =0x0C000018 which causes a jump to 0x0C000018
(It actually jumps to the location specified at location 0x00000618 which happens to be 0x0C000018)

By default, location 0x0C000018 jumps to the location stored in 0x0C00009C.
So I just leave this alone and put the address of my IRQ handler in location 0x0C00009C

Here are code snippets of the firmware:

The IRQ handler:

__attribute__ ((interrupt("IRQ"))) void IRQ_handler(void)
{
*I_ISPC |= 0x00000080; // Clear the pending interrupt condition, 0x80 = 1 << 7, INT_URXD0

receive_buffer[receive_in_index] = *URXH0;
receive_in_index = (receive_in_index+1) & (RECEIVE_BUFFER_SIZE-1);
}

The IRQ init:

void irq_init()
{
*INTMSK = 0x07FFFFFF; // Disable all interrupts
*INTCON = 0x00000005; // Configure the interrupt controller for non-vectored IRQ
*((uint32_t *)0x0C00009C) = (uint32_t)IRQ_handler; // Set the IRQ handler location
*INTMSK &= (~0x00000080); // Enable the UART RX0 interrupt
*INTMSK &= (~0x04000000); // Enable global interrupts
}

Thats it. Other IRQs should be able to be used as well by enablinng the proper interrupt and checking in the handler for which interrupt caused the handler to be called. The proper interrupt pending bit will need to be cleared as well.

I don't see why fast interrupts (FIQ) shouldn't work also by changing INTCON, but I've not tried this yet.

I don't think vectored interrupts can be used because the vector addresses do not appear to be confgured in ROM

01-17-2007 23:08:51

Reply to Thread | Printer |
All times are PSTPowered by UltraBoard v1.62



Copyright © 2000, Netmake Inc. All Rights Reserved.
See Terms and Conditions for more information.




i-opener opener laptop notebook computer help drivers dll free windows dos repair fix linux mac macintosh 2000 95 98 nt pc configure hardware software sound video netscape explorer network networking lan wan software cmos fat bios printer card mouse modem ide scsi cd rom controllers scanner tape hard drive cgi scripts source code mp3