CCS/UCD3138: The confirmation ABORT

Then, I used the debugger to perform step execution at the assembler level.
The following screen was displayed.

I'm not sure what's happening with the JTAG debugger, I haven't tried to single step through an abort.  Often in circuit emulators struggle with things like that.  

There probably is a data abort happening.  I can try to describe it, but I think it is better to introduce you to the ARM7TDMI Technical Reference Manual here:

https://static.docs.arm.com/ddi0029/g/DDI0029.pdf

I suggest you read the first 2 chapters, up through 2.8 - Exceptions.  This will give you the foundation in the processor, give you a correct and detailed description, and introduce to a very useful piece of documentation if you are going to dive into the details of the ARM7 core further.  

You're already doing a data abort, I suspect.  To do a prefetch abort, just arrange to jump to an illegal address.

For an illegal instruction abort, I found a web page that claims to have an illegal instruction code.  Use the code and the web page at your own risk.  It does look safe to me, but no guarantees:

https://stackoverflow.com/questions/11851976/arm7-tdmi-undefined-instruction-exception-manual-generation

On our compiler, all you need to do to insert the instruction code is to put this in your C code wherever you want it:

asm("  .long 0x26889912;") // bad opcode from third party website

Note that the space after the first " is important to the assembler.  

In general, you will find that if you google your questions with ARM7TDMI, you will often find an answer.  Billions and billions of ARM7 cores have been sold in lots of places, so there is lots of information out there.  You can most likely get a quicker answer that way.  

Thank you for your reply.

It's a bit different from the answer I'm asking for, so I'd like to give you some additional background information.


The intention of this question is
It is to confirm that the process at the time of occurrence was added to the function of the abort handler.
Currently, the processing at the time of occurrence is tentatively as follows.

interrupt.c

#pragma INTERRUPT(abort_data_fetch_exception,DABT)

void abort_data_fetch_exception(void)

{

   XXX = 1; // Substitution process for variables

   for( ; ; );

}

void abort_prefetch_exception(void)

void undefined_instruction_exception(void)

Same processing for the above two.

It really seems like if you've gotten one working, the other one should work too.  Just to check, did you put the I/O line toggle in the exception handler for the data abort as well?  

Yes, the waveform remained off even if I / O line ON signal was set to the abort data handler (void abort_data_fetch_exception (void)).

The following code was executed in "standard_interrupt.c" to confirm that the abort handler was called.

                 void (* func) () = 0x10000000;

                 (* func) ();

In the abort handler, the processing to turn on AC_FAIL_IN of I / O line is entered.

・ void abort_prefetch_exception (void) {

MiscAnalogRegs.GLBIOVAL.all | = MASK_AC_FAIL_IN;

}

・ void abort_data_fetch_exception (void) {

MiscAnalogRegs.GLBIOVAL.all | = MASK_AC_FAIL_IN;

}

System Exception Control Register (SYSECR)

System Exception Status Register (SYSESR)

Abort Exception Status Register (ABRTESR)

As a result, the registers have the following values ​​after the abnormal processing occurs.

The table below shows a summary of the changes.

Since the above ABRTESR.bit.ADRABT is 1, I think that an illegal address abort has occurred.

However, I don't understand why the handler (void abort_prefetch_exception (void) or void abort_data_fetch_exception (void)) is not called even though the abort occurred. Is any necessary operation missing?

Also, please tell me how the PWM signal stops when an abort occurs.

I believe that the PWM output will continue to be output even if an abort occurs.

Addendum

When the error handling currently performed in standard_interrupt.c is performed in main.c, the I / O line signal turns ON.

Is there a way to execute the abort handler

(void abort_prefetch_exception (void)

or void abort_data_fetch_exception (void))

in standard_interrupt.c (IRQ) or interrupt.c (FIQ)?

bet regards.

This one is going to take some research on my part.  I haven't tried executing the code in the standard interrupt before. The reason the PWM is getting turned off is that the processor is getting reset.  The bit in SYSESR shows that the abort is occurring.  Normally the reset is caused by an additional fault occurring on the way to the abort interrupt.  I'm going to need a little time to look into this one and see if I can duplicate your results.  and maybe talk to the designers.  

Are there other things going on in standard interrupt.c that could have any bearing on this?  Do you have the watchdog enabled?

The PWM signal stops because the device is being reset by the abort somehow.  

I can't think of any reason why the abort shouln't work in the standard interrupt as well as in main.c.  

Have you tried it with the JTAG disconnected?  If you have a breakpoint set somewhere, that could interfere with the normal function of the abort, for example.  

And it is really with a UCD3138 that you are trying this, right?  If I have to test it, I want to do it on the correct device.  

Well, I've managed to duplicate your results, but I had to write to the SYSECR register to get an exact duplication.  

When I put the function call to an illegal address in background, it went to the abort.

When I put the function call to an illegal address in the standard interrupt, it reset the device and turned the DPWM off, and then either stayed in ROM mode or restarted, as I expected.  With the checksum in place and it going into ROM mode, I could tell because the DPWM stopped for 10 milliseconds.  This is because the ROM takes 10 msec to calculate the checksum.  It's easy to miss this unless you are looking for it.  I put out a signal on an I/O pin just before doing the illegal function call and triggered on that.

However, if I set the PACCOVR, ACCOVR, and ILLOVR bits in the SYSECR, I get the DPWM staying on and the program getting lost.  Somehow it isn't going to the ABORT, and it isn't getting reset either.  

That's what I see.  Can you tell me what you are trying to accomplish with the ABORT.  if you want a reset, I think that you are getting that, as long as you don't set those bits.  Unless you have a code that can cause the issue without setting those bits.  If you have a code which does that, perhaps you can reduce it to the minimum, remove any proprietary elements and send it to me, and I can see if I can duplicate it.  

I'm pretty sure that what we both see is what will happen with the device, so if you can tell me what you are trying to accomplish, I can try to help you with that.  After all, the device is its own best documentation.  

Thank you for your research.

What I want to do when an ABORT occurs is to output a signal from the I / O line to the outside of ucd3138 and keep the program inside the abort handler.

After that, I want to reset from outside instead of ucd3138.

There were some differences between Ian's research results and my event, so I asked the reply to ask questions in red.

It is shown below.

(20200515 Mr. Ian’s Reply)

When I put the function call to an illegal address in the standard interrupt, it reset the device and turned the DPWM off, and then either stayed in ROM mode or restarted, as I expected. With the checksum in place and it going into ROM mode, I could tell because the DPWM stopped for 10 milliseconds. This is because the ROM takes 10 msec to calculate the checksum. It's easy to miss this unless you are looking for it. I put out a signal on an I/O pin just before doing the illegal function call and triggered on that.

Q1. I think that the abort handler is not called during this research. Is there any recognition?

Q2. Ian says that in the research of abnormal operation without setting SYSECR, PWM will be in either restart mode or ROM mode after being stopped for 10ms. What happens to each?

Q2_1 When restarting

I think that the PWM will turn on and off again, is this correct?

Q2_2 ROM mode

I think that PWM does not repeat ON / OFF after stopping for 10ms. Is it correct?

I don't have much understanding about ROM mode, so please tell me the materials.

However, if I set the PACCOVR, ACCOVR, and ILLOVR bits in the SYSECR, I get the DPWM staying on and the program getting lost. Somehow it isn't going to the ABORT, and it isn't getting reset either.

    Q3. Does the DPWM stay on (staying on…) mean that it remains ON (High level)? Or does it mean that the ON / OFF control is continued?

Also, I confirmed from the JTAG debugger that each OVR register of SYSECR is not set (remaining 0) in both the back ground loop (main.c) and IRQ (standard_interrupy.c).

Best Regards.

Thank you for your reply.

The waveforms so far have been implemented with the checksum enabled. (See Figure 1 below)

conditions:

AC_FAIL_IN I / O Line toggle set in abort_prefetch_exception ()

Prefetch abort execution @standard_interrupt () (IRQ)

result:

DPWM stops due to abnormal operation. (The abort handler is not called.)

When the ENABLE signal (ON / OFF switch on the evaluation board) was turned OFF / ON in this state, the PWM was turned OFF / ON again. (See Figure 2 below)

From this, I think that it is restarting from address 0 due to illegal processing.

One concern is that the Enable signal is not recognized even though it is in the ON state.

I would like to know the specifications of the Enable signal. (Level detection? Edge detection?)

Best regads.

Looking at that, it suggest that while the background program is getting lost, the standard interrupt is still running, since an enable/disable generally makes the system go to idle mode and back to restarting.   The best way to protect against that is to have the watchdog running and have only the background loop keeping the watchdog from resetting the processor.  That way if the background loop gets lost, the processor will be reset by the watchdog.  

To see if this is happening, I'd suggest having the standard interrupt toggling an I/O line everytime it is entered, and see if this line keeps toggling.