Hello George, In this context I recommend to use VECTOR (ABS,CODE) with a .org 0x0000. The .globl __interrupt_vect can probably be left out.
I personally do not fully agree with the chosen solution in the wiki, because usually the code memory is flash that needs to be erased in pages and not bytes. To program the interrupts you need to erase the first page and thus the reset vector. If power fails during erasure you will have a dead device. I would recommend to keep the bootloader in low memory and relocate the application instead. The bootloader then needs to forward all interrupt vectors to the application area. This can be done in assembly. This can include detection if your in the bootloader and jump to either the bootloaders ISR or the applications ISR. If your bootloader can do without interrupts things are easier though. How do you intend to overcome the problem of both the bootloader and the application using the dma_ISR and "don't overwrite each other"? Greets, Maarten > Hello all and apologies for the length in advance. I'm working on a UART > bootloader for the cc2430. In the longer term it will be co-hosted with > images of the contiki-os. > > I started with the info found in the relevant tutorial on the sdcc wiki. > Let me start by saying many many thanks for publishing it, it explains > things very nicely - I'd have no clue where to start otherwise. > > So, I downloaded the example from github and built it (for the record > one needs to rename the assembler executable in the makefile first). I > then noticed that the 'magic' VECTOR area was being relocated as well. > >From reading the wiki page, I understand that the whole point is to keep > VECTOR at the start of the code area and relocate everything else. Am I > misunderstanding things or has something perhaps changed in SDCC between > the tutorial and now? > > I then made the following changes to the tutorial's crtstart.asm and > tried it with my code: > - I changed VECTOR from (CODE) to (ABS,CODE). > - I tried with .org 0x0000 as well as without. Both worked > - I tried with the .globl __interrupt_vect directive as well as without. > Again, both worked > > My question here is, am I on the right track? Will any of the > combinations above come back and bite me? What's the best way to achieve > things? > > One further requirement is that my bootloader needs to be able to use > interrupts. Things didn't work off the shelf so I manually added my ISRs > in crtstart.asm, like: > ... > ljmp _dma_ISR > .ds 5 > ... > > Again, things seem to be working but I'd like your comments on whether > this is the recommended way to do it or if I'm playing with fire. > > My current crtstart.asm is at the end of the message. If you guys can be > bothered with having a look at it and send your comments, I'd greatly > appreciate it. > > One last question is: The user apps will also use interrupts and will > use code banking. Any special requirements in order to co-host it with > the boot loader in addition to the obvious "don't overwrite each other"? > I should think that --code-loc would be enough, so long as the loader is > smart enough to jump to the app's start address? > > Thanks ever so much for reading this far and for any replies. > George > > crtstart.asm: > ============== > .globl __start__stack > ;-------------------------------------------------------- > ; Stack segment in internal ram > ;-------------------------------------------------------- > .area SSEG (DATA) > __start__stack: > .ds 1 > > .area VECTOR (ABS,CODE) > __interrupt_vect: > ljmp __sdcc_gsinit_startup > reti > .ds 7 > ljmp _dma_ISR > .ds 5 > reti > .ds 7 > reti > .ds 7 > reti > .ds 7 > reti > .ds 7 > ljmp _port_0_ISR > .ds 5 > reti > .ds 7 > ljmp _port_1_ISR > .ds 5 > reti > .ds 7 > ljmp _watchdog_ISR > > .globl __start__stack > > .area GSINIT0 (CODE) > > __sdcc_gsinit_startup:: > mov sp,#__start__stack - 1 > > .area GSFINAL (CODE) > ljmp _loader_main > > > ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
