LeafLabs Garden

A place to share, learn, and grow...

1. 

   gbulmer
   Moderator

   konan - the mechanism we have described doesn't let you do what you describe directly.

   By providing an interrupt handler called, for example, __irq_adc(), there is no record of the previous interrupt handler; your definition of (in this example) __irq_adc() replaces it completely at link time.

   As many of the handlers are dummy 'do nothing' handlers, this isn't a bad problem.

   There are several ways, some quite involved, of getting an effect similar to the one you describe.
   One involves copying the entire interrupt vector table, at run time into RAM, filling in the address of your handler in the copy, and choosing which interrupt vector table to allow the interrupt hardware to use.

   What is it that you need to do? We might be able to suggest a way to get the result you need.

   Posted 4 years ago #
2. 

   konan
   Member

   gblumer - thanks for explanation and sorry for late reply :) I holded over that project, but returned to it now. As far as I understood, at boot time the vector table is allocated in flash memory, and the only way to change the single vector is to copy the entire table into RAM, and call nvic_set_vector_table? The original vector table can be found at address from SCB_BASE->VTOR, am I right?

   Posted 2 years ago #
3. 

   gbulmer
   Moderator

   konan - If I understood your needs, then you want to have both your interrupt handler, and the 'initial' interrupt handler able to run

   There are, at least, two ways to do this:
   1. Save the initial, in Flash, vector table base address (VTOR), build a new interrupt vector table in RAM (copy the old one and change the entry you want to handle), set the NVIC base register (VTOR) to point to the in-RAM interrupt vector table. Then your interrupt handler does as you describe, using the initial interrupt vector table value when it needs it.

   2. Implement x893's mechanism, described at the head of this thread, for the interrupts you want to override, with the added ability to save previous interrupt vector values when attaching.

   As you have found, VTOR is in the SCB block. According to the ARM document "ARM v7-M Architecture Reference Manual" DDI0403D_arm_architecture_v7m_reference_manual.pdf
   the NVIC vector base register is at 0xE000ED08, so you could grab that value ((unint32**)0xE000ED08) and print the existing vector table. It will have a bunch of values that point to the same interrupt handler.

   So you could allocate an array of uint32's (or void *):
   uint32* vectors[256];

   copy the flash table to RAM,
   

   uint32* flash_vectors = *((unint32**)0xE000ED08);
   int i;
   for (i=0; i<256; ++i) {
       vectors[i] = *flash_vectors;
       ++flash_vectors;
   }

   set the VTOR to point to the start of it,
   *((unint32**)0xE000ED08) = &vectors[0];
   and if you got it right, everything should continue to work!-)

   WARNING: THAT CODE IS UNTESTED, NOT EVEN COMPILED.

   Posted 2 years ago #
4. 

   konan
   Member

   gbulmer, thanks again, I'll try this. By the way, about the topic of this thread - I think, copying and modifying the vector table in RAM is much easier way to change any vector we need. It may be done by creating the library, that at start will copy the vector table, and then change any vector(s). With the ability to call "old" irq handlers, using vectors from the original VT in flash.

   PS why vectors[256]? according to RM0008, the last vector offset is 0x12c, so there's only 75 vectors...

   Posted 2 years ago #
5. 

   konan
   Member

   Something strange. I tried to copy the VT to the RAM, and give new address to the NVIC, but Maple hangs at boot time. here's the code:

   #include "scb.h"
   #include "nvic.h"

   typedef void (*inthand)(void);
   inthand NVT[75]; // new vector table

   void setup() {
   inthand *fvt; // flash vector table

   fvt = (inthand*)SCB_BASE->VTOR;

   for (int i=0; i<75; i++)
   NVT[i] = *(fvt++);
   nvic_init((uint32)&NVT, 0);
   }

   void loop() {
   SerialUSB.println((uint32)NVT[55], HEX);
   delay(1000);
   }

   When I comment out the "nvic_init" line, everything works fine, the value printed to SerialUSB is identical to the value from flash (SCB_BASE->VTOR+0xDC).

   Posted 2 years ago #
6. 

   gbulmer
   Moderator

   konan - "PS why vectors[256]? according to RM0008, the last vector offset is 0x12c, so there's only 75 vectors..."

   I believe that no Cortex-M3 has more than 256 vectors. So that is robust though wasteful :-)
   According to PM0056 rev4, http://www.st.com/web/en/resource/technical/document/programming_manual/CD00228163.pdf
   there 81 interrupts, so I'd probably use that figure for copying.

   I apologise, I forgot about another complication; the vector table start address must be aligned to 128 bytes, i.e. the bottom 7 bits of the address must be 0, see PM0056 rev4, "4.4.4 Vector table offset register (SCB_VTOR)".

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.