Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Parallel Master Port (PMP) slave mode interrupts
07-04-2017, 01:19 AM,
#1
Question  Parallel Master Port (PMP) slave mode interrupts
I'm not sure whether this is the right forum, but I have been experimenting with PMP and the slave mode, where the PIC32MX should respond to signalling on various pins.

So far, I've looked at the Microchip documentation (DS60001168J for the PIC32MX270F256B) and the reference material on PMP (DS60001128H, "Section 13. Parallel Master Port (PMP)"), and I think I have managed to get the device to react to changes in the chip select and read pins. This actually didn't work at all until I encountered some advice about needing to reset the analogue state of the I/O pins (using the ANSELA and ANSELB registers), which the documentation doesn't bother to remind the reader about.

However, I'm now trying to find examples where interrupts are configured for PMP slave modes, so that a program can react to reads and writes when they occur. Unfortunately, this doesn't seem to be very common (in public information on the Internet), and what I have seen seems to involve other PIC architecture products. I suspect that the behaviour is not quite the same between the different architectures, and the details are certainly not exactly the same (not even between different PIC32 products, in fact).

Does anyone have any experience doing this with PIC32 products? (I'm actually writing the code in MIPS32 assembly language and using a breadboard circuit, but I have managed to do things like flash the device, install an interrupt handler in the right place, demonstrate a timer interrupt with digital outputs, and so on. So I'm hoping that this configuration won't somehow be a problem doing this kind of experimentation.)
Reply
10-04-2017, 04:06 PM,
#2
RE: Parallel Master Port (PMP) slave mode interrupts
All you need to know is in Datasheet Section 13. Parallel Master Port (PMP) :
- 13.4 SLAVE MODES OF OPERATION
- 13.5 INTERRUPTS

The Parallel Master Port module has the ability to generate an interrupt, depending on the selected operating mode.
In your case : EPSP (Enhanced Addressable Slave) mode.
You'll get then :
- Interrupt on every read and write byte
- Interrupt on read or write byte of Buffer 3 (PMDOUT<31:24>), PMA<1:0> = 11.
The PMP module is enabled as a source of interrupt via the PMP Interrupt Enable bit, PMPIE.
The Interrupt Priority bits (PMPIP<2:0>) and Interrupt Subpriority bits (PMPIS<1:0>) must also be configured.
The PMP Interrupt Vector (INT_PARALLEL_MASTER_PORT_VECTOR) has number 35.
There are two PMP IRQ (INT_PARALLEL_MASTER_PORT, number 48 and INT_PARALLEL_MASTER_PORT_ERROR, number 49). Vector and IRQ numbers are given for the PIC32MX2xx family.
The PMPIF bit must be cleared in software.
It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
10-04-2017, 06:19 PM,
#3
RE: Parallel Master Port (PMP) slave mode interrupts
Thanks for the reply, regis! I actually managed to enable interrupts, having made a stupid mistake with the bitfields in the IEC1 register, but I did see some rather strange behaviour once I started to handle the interrupts.

My test program has a main thread which just flashes an LED using one of the outputs (not one associated with PMP, by the way). Once interrupts started to be produced from slave mode read requests, my handler would populate PMDOUT - here, I'm just using the "legacy" mode with one output register - and would clear PMPIF afterwards. But after a while, the main thread would slow right down, indicating that some interrupt condition was being caused but not handled.

I did see other conditions occurring for interrupts that were not enabled. For instance the INT1IF and INT2IF bits of IFS0 would actually change, even though I am not using external interrupts at all. But importantly, the PMP error interrupt was being generated (setting PMPEIF), and it was actually this that was causing the slowdown.

Now, PMPEIF seems to be under-documented, and merely clearing PMPEIF is not sufficient. It appears that to clear the condition completely, you also have to (1) disable PMP interrupts using IEC1, (2) disable PMP using PMCON, (3) enable PMP interrupts again using IEC1, (4) enable PMP using PMCON. Then, the system will recover and PMP activities will resume.

Of course, PMPEIF indicates something wrong, and my test circuit is not exactly robust, but I didn't find anything actually describing this error condition, not in section 13 or in the device datasheet. So, maybe this way of handling such conditions is flawed, but I have no real way of evaluating that with the information I have seen.

At some point, I'll make my code available in the context of a useful project. But thanks once again for your assistance!

(I guess it might also be interesting for me to describe my breadboard circuit, which I discovered from looking around on the Internet and on the Pinguino wiki, as well as the way I program it, which is not the method apparently preferred by most people, but instead uses a project called ArduPIC that employs a vanilla Arduino board as a JTAG programmer. This seemed to be the most gentle way of getting started.)
Reply
22-04-2017, 07:39 PM, (This post was last modified: 26-04-2017, 05:57 PM by pboddie.)
#4
RE: Parallel Master Port (PMP) slave mode interrupts
Well, after some more testing, it seems as if I have problems with the PMD3, PMD4 and PMD5 outputs which are always set high when reading from the PIC32. On my device, these pins are shared with the JTAG programming functions (TDO, TCK, TDI), and although I do use the JTAG pins to program the device, I disconnect MCLR# (pulling it up to VDD) before trying to use the device.

Does anyone have any experience with this kind of problem? All the other data pins work fine.

Edit...

Disabling PMP and setting TRISB bits to make various pins outputs (RB7, RB8, RB9, plus others to test with) and setting PORTB bits to zero seems to indicate that RB7, RB8 and RB9 corresponding to PMD3, PMD4 and PMD5 get stuck high for some reason. I wonder what I have missed here.

Edit...

It appears that since I am programming using JTAG, I cannot disable the JTAG pin assignments using either CFGCON or DEVCFG0 and the JTAGEN control bit. So, I cannot make these pins behave appropriately. I'm just updating this since Microchip cannot be bothered to actually write this up anywhere obvious. I guess I'll have to use ICSP for programming instead.

Edit...

Well, I finally got all this mostly working. What I needed to do was to clear the DEVCFG0 JTAGEN bit when flashing the device, which you cannot do with JTAG, apparently, but I wasn't attempting to do so, anyway. Indeed, this is what seems to be done when people write "#pragma config JTAGEN = ..." in their Microchip-specific programs, and the equivalent in the world of binutils and the normal tools is to declare the memory in the linker script and then to set DEVCFG0 in a specific section in one's program. Once this is done, it may also be necessary to clear CFGCON and its differently-located JTAGEN bit during the initialisation of the running program. Then, the PMD bits are actually available to the PMP peripheral.

For ICSP programming I used the Nanu Nanu software for the Arduino and the Pickle tools. Both of these seemed more robust and more clearly documented than the suggested approach on the Pinguino wiki. I intend to write much of this up properly in due course.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)