• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 103 subscribers
  • Views 1840 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3358 interrupts without OS/starterware

Pavel Hudecek
Prodigy 60 points

Hi,

how can i setup interrupts in simple project, whitch not contains OS nor Starterware? I try instructions from spruh73 manual, chapter 6.2.1. This is understandable. But how can i set interrupt vector?

For example, i want interrupt from GPIO1 bit 12, falling edge, to be execute my function declared as "static void gpio1_12isr()": What i must to do?

  • 0
    TI__Guru**** 393215 points

    Hi Pavel,

    The best way to go I can suggest to you is to begin from Starterware. It has a dedicated forum for support: http://e2e.ti.com/support/embedded/starterware/f/790 This forum supports only the Linux SDK.

  • 0
    Mastermind 8020 points

    I've posted a pure-assembly example for the beaglebone black a while ago here.  I've also been working on more elaborate baremetal examples but haven't had much time yet. Anyhow, I've taken a current snapshot with non-working/unfinished stuff removed so it's basically at the functionality of the original example, but now mostly written in a rather idiosyncratic style of C++ which people will probably either love or hate (or maybe just take a bit of time to get used to): io-irq.tar.gz

    Like the original it's a purely irq-driven GPIO example (toggles leds based on button press). The startup code has some minor cleanups, and should now also work if for some reason you want to assemble it in ARM-mode rather than Thumb-mode (although in ARMv7 there's really no reason to ever do that). To make sense of the code style you'll definitely want to read include/defs.h and if necessary brush up on recent C++ additions. Alternatively, you can pretend it's just some unfamiliar language: I think it's quite readable. (If possible, add a syntax highlighting rule to your editor to highlight "let" as a statement.)

    It requires gcc 4.9 to compile, 4.8 will not do.  I've tested it against the gcc-linaro-arm-none-eabi-4.9-2014.09 toolchain, although I get significantly smaller executables with a custom-built toolchain.  I've included the build output in the archive: build/demo.bin is a valid MLO so if you name it that and put it in the root of a fat32-formatted μSD card and boot from it. (Yes, the whole app is only 668 bytes. Actually, with additional size-optimization options it's 584 bytes.)  Alternatively you can upload build/demo.elf via JTAG.  Beware that U-Boot already seems to do some reconfiguration which breaks the program if you upload it via JTAG.  Powering up the BBB with the sd-boot button (SW2) held pressed will prevent u-boot from starting, and then upload via JTAG works, and there are a variety of other ways of loading the code onto the target.

    Of course if your target isn't a beaglebone black then you'll probably need to modify the example to make sure it doesn't drive signals onto inappropriate pins.

    I hope this is of any use, and with a bit of luck I'll have a more complete example in the future: mmu/cache setup is very important for performance (I already posted a chunk of code on that subject), and I hope to be able to make a nice uart example (especially since the Starterware UART code is really quite broken.)

  • 0 in reply to Matthijs van Duin
    Prodigy 60 points
    Thank you,
    referenced examples helped me a lot.
  • 0 in reply to Matthijs van Duin
    Expert 1315 points
    Matt, ok i am totally impressed. but weaving thru this example is more complicated than the task at hand, a bare metal interrupt elf.
    I am stuck with my first interrupt demo. I may fix it with your .ld script.
    Why do you use mlo if you load via jtag?

    thanks, later...............dd
  • 0 in reply to Don Lawrence
    Mastermind 8020 points

    Don Lawrence said:
    weaving thru this example is more complicated than the task at hand, a bare metal interrupt elf

    The C++ version mostly looks fancy, it doesn't actually do much more than the assembly version.

    Don Lawrence said:
    I am stuck with my first interrupt demo. I may fix it with your .ld script.

    Feel free to use any part of either version if it helps you, though I don't see how the linker script is relevant for irq handling. Note that the C++ version in this thread is a bit old, the linker script of the revised assembly version I just posted in that thread is most up-to-date with my own code, although I commented out the parts for bss and initializers since the assembly code is minimalistic and doesn't include support for them.

    Beware that my linker script does somewhat tie into my start.S and compiler options, and mixing it with a different codebase is very likely to result in failure. I've specifically designed the linker script to fail if it encounters any non-empty unknown section (the linker's default behaviour is to guess where to put it).

    The essential part of irq handling is in start.S (C++ version and original assembly version) or vectors.S (revised assembly version).  The C++ version also has a tiny bit of support code in separately in irqs.cc. If you look at the disassembly you'll notice the C++ version isn't really more complicated, just a bit less efficient. (Note that the C++ version actually generates a smaller executable because it places the irq dispatching table in .bss and fills it in at runtime while the assembly version includes the whole 128-word table as static data.)

  • 0 in reply to Don Lawrence
    Mastermind 8020 points

    Don Lawrence said:
    Why do you use mlo if you load via jtag?

    I just realized I hadn't answered that part:

    My makefile simply generates output for all three methods of booting: an ELF file for loading via JTAG, a bin file for peripheral booting, and an MLO for memory booting.