Hello,
I am new here. . first post.
I have written code on a HCS12 uC (Dragon 12Plus Board) that
meets the write wave form (HAS unused) in the HPI Ref. Guide. I verified this
on a MSO2014; by verified I mean my HCNTL bits, HCS, and HSD1 bits are all
jiving (it looks right) I am simulating HRDY by sending out a manual burst
signal on a function generator.
I am using a DSK6713, no daughter card, I am just using the complimentary cable
for the micropitch header on the board (requested a sample from Samtec, 40$
cable for free. . or in my case, 2 for 1)
Two Questions (if you please. . .)
1. It does not appear that the EDMA needs to be configured by me. I am
referencing
spra720, page 4. It states the following:
Host port servicing is performed without any user intervention. The HPI has a
direct connection
to the EDMA and is not programmable by the user. The requests made to the EDMA
are
dependent on the host activity, but consist of transfers between the HPI data
register (HPID) and
the rest of the system memory. An EDMA channel invisible to the user is set
aside for this task
and is not configurable. The host port is capable of transferring data to or
from any location in
the DSPs memory map
Does this mean I don't need to worry about programming this at all. I want
to write a simple piece of test code to verify values I am writing. Do I need
to enable interrupts in the test code? or does it just magically happen as the
above document states.
2. I also read that the EDMA sees the DSPINT as an event from the HPI. Right now
I am just writing 0 to HPIC. I am assuming that HSTROBE' going low kicks
things off, i.e. generates the event for the HPI; am I interpreting this
right.
3. Does anybody have an opinion on whether I should connect the grounds of the
development boards? I am not sure which way to go on this; my gut tells me the
grounds on each board should be common.
O.K. I appreciate anybody who would like to share with me some HPI wisdom
Cheers,
Jonesy
_____________________________________
6713 DSK HPI and EDMA Configuration
Started by ●January 20, 2011
Reply by ●January 20, 20112011-01-20
Michael-
Ah, another in the long line of OIT students doing DSP. Did you know that OIT has had DSP classes and labs since the
early 1990s? TI should fund an extension to the campus there, hehe.
> I am new here. . first post.
> I have written code on a HCS12 uC (Dragon 12Plus Board) that
> meets the write wave form (HAS unused) in the HPI Ref. Guide.
> I verified this on a MSO2014; by verified I mean my
> HCNTL bits, HCS, and HSD1 bits are all jiving (it looks right)
> I am simulating HRDY by sending out a manual burst
> signal on a function generator.
>
> I am using a DSK6713, no daughter card, I am just using the
> complimentary cable for the micropitch header on the board
> (requested a sample from Samtec, 40$ cable for free. . or
> in my case, 2 for 1)
>
> Two Questions (if you please. . .)
> 1. It does not appear that the EDMA needs to be configured
> by me. I am referencing
> spra720, page 4. It states the following:
>
> Host port servicing is performed without any user
> intervention. The HPI has a direct connection
> to the EDMA and is not programmable by the user. The
> requests made to the EDMA are dependent on the host
> activity, but consist of transfers between the HPI
> data register (HPID) and the rest of the system
> memory. An EDMA channel invisible to the user is set
> aside for this task and is not configurable. The
> host port is capable of transferring data to or from
> any location in the DSPs memory map
>
> Does this mean I don't need to worry about programming
> this at all. I want to write a simple piece of test
> code to verify values I am writing. Do I need to
> enable interrupts in the test code? or does it just
> magically happen as the above document states.
It "magically" works. You do not need to configure EDMA and you don't need interrupts -- at least for basic HPI
communication. You can add host-to-DSP (DSPINT) and vice-versa (HINT) interrupts later, as you develop DSP and host
side software and the need arises (for example if you don't want to poll when a DSP data buffer is ready).
> 2. I also read that the EDMA sees the DSPINT as an
> event from the HPI. Right now I am just writing 0 to
> HPIC. I am assuming that HSTROBE' going low kicks
> things off, i.e. generates the event for the HPI;
> am I interpreting this right.
> 3. Does anybody have an opinion on whether I should connect
> the grounds of the development boards? I am not sure which
> way to go on this; my gut tells me the grounds on each board
> should be common.
Assuming you have the power jacks on both boards connected to wall warts and the wall warts are plugged into the same
power strip, you should be fine. It might be a good idea to power the boards off/on simultaneously, and not leave one
on when the other is not. I don't know what your Dragon 12Plus board does with its IO lines immediately after
power-up but in any case it's probably better if the Dragon is not driving the lines when the DSK C6713 is not powered
on.
As for getting HPI to work, here is some advice:
1) What you said about using a function generator for HRDY above -- do not do that. The C6713 will generate HRDY,
that's its job, and your host (Dragon 12Plus board) needs to pay careful attention to HRDY, that's its job. If HRDY
never goes high then something is wrong -- somehow you got the HPI internal state-machine stuck. Probably only a
C6713 Reset fixes that.
2) Carefully study TI docs on HPI read/write sequence. Typically you have /HCS enabled; in fact it's Ok to leave it
like that. Then check HRDY, if low wait, when high perform the transfer. Make sure that HR/W is set before /HDS
(strobe).
3) Debug strategy: get read working first. Initially just read the HPIC register, as it contains a known value after
power-on/Reset. Don't worry about anything else until you have reliable read. Next step is to write/read the HPIA
register (get back what you wrote). When you think that's working, then write the HPIA with value x, then write the
HPIC with a value (something that won't cause a problem, for example set the HINT bit), then read HPIA again. Is it
still x? If not you're getting a "bus hold" result and your write timing is not yet good.
4) Your cable has to be very short and the 12Plus should have substantial drive capability on its I/O lines, maybe 15
to 20 mA at 3.3V. You should carefully check /HDS on your MS0-2014 scope and make sure it doesn't have falling edge
glitches that could be interpreted as a double-strobe. Also make sure overshoot and undershoot (ringing) are within
TI's specs.
-Jeff
_____________________________________
Ah, another in the long line of OIT students doing DSP. Did you know that OIT has had DSP classes and labs since the
early 1990s? TI should fund an extension to the campus there, hehe.
> I am new here. . first post.
> I have written code on a HCS12 uC (Dragon 12Plus Board) that
> meets the write wave form (HAS unused) in the HPI Ref. Guide.
> I verified this on a MSO2014; by verified I mean my
> HCNTL bits, HCS, and HSD1 bits are all jiving (it looks right)
> I am simulating HRDY by sending out a manual burst
> signal on a function generator.
>
> I am using a DSK6713, no daughter card, I am just using the
> complimentary cable for the micropitch header on the board
> (requested a sample from Samtec, 40$ cable for free. . or
> in my case, 2 for 1)
>
> Two Questions (if you please. . .)
> 1. It does not appear that the EDMA needs to be configured
> by me. I am referencing
> spra720, page 4. It states the following:
>
> Host port servicing is performed without any user
> intervention. The HPI has a direct connection
> to the EDMA and is not programmable by the user. The
> requests made to the EDMA are dependent on the host
> activity, but consist of transfers between the HPI
> data register (HPID) and the rest of the system
> memory. An EDMA channel invisible to the user is set
> aside for this task and is not configurable. The
> host port is capable of transferring data to or from
> any location in the DSPs memory map
>
> Does this mean I don't need to worry about programming
> this at all. I want to write a simple piece of test
> code to verify values I am writing. Do I need to
> enable interrupts in the test code? or does it just
> magically happen as the above document states.
It "magically" works. You do not need to configure EDMA and you don't need interrupts -- at least for basic HPI
communication. You can add host-to-DSP (DSPINT) and vice-versa (HINT) interrupts later, as you develop DSP and host
side software and the need arises (for example if you don't want to poll when a DSP data buffer is ready).
> 2. I also read that the EDMA sees the DSPINT as an
> event from the HPI. Right now I am just writing 0 to
> HPIC. I am assuming that HSTROBE' going low kicks
> things off, i.e. generates the event for the HPI;
> am I interpreting this right.
> 3. Does anybody have an opinion on whether I should connect
> the grounds of the development boards? I am not sure which
> way to go on this; my gut tells me the grounds on each board
> should be common.
Assuming you have the power jacks on both boards connected to wall warts and the wall warts are plugged into the same
power strip, you should be fine. It might be a good idea to power the boards off/on simultaneously, and not leave one
on when the other is not. I don't know what your Dragon 12Plus board does with its IO lines immediately after
power-up but in any case it's probably better if the Dragon is not driving the lines when the DSK C6713 is not powered
on.
As for getting HPI to work, here is some advice:
1) What you said about using a function generator for HRDY above -- do not do that. The C6713 will generate HRDY,
that's its job, and your host (Dragon 12Plus board) needs to pay careful attention to HRDY, that's its job. If HRDY
never goes high then something is wrong -- somehow you got the HPI internal state-machine stuck. Probably only a
C6713 Reset fixes that.
2) Carefully study TI docs on HPI read/write sequence. Typically you have /HCS enabled; in fact it's Ok to leave it
like that. Then check HRDY, if low wait, when high perform the transfer. Make sure that HR/W is set before /HDS
(strobe).
3) Debug strategy: get read working first. Initially just read the HPIC register, as it contains a known value after
power-on/Reset. Don't worry about anything else until you have reliable read. Next step is to write/read the HPIA
register (get back what you wrote). When you think that's working, then write the HPIA with value x, then write the
HPIC with a value (something that won't cause a problem, for example set the HINT bit), then read HPIA again. Is it
still x? If not you're getting a "bus hold" result and your write timing is not yet good.
4) Your cable has to be very short and the 12Plus should have substantial drive capability on its I/O lines, maybe 15
to 20 mA at 3.3V. You should carefully check /HDS on your MS0-2014 scope and make sure it doesn't have falling edge
glitches that could be interpreted as a double-strobe. Also make sure overshoot and undershoot (ringing) are within
TI's specs.
-Jeff
_____________________________________
Reply by ●January 21, 20112011-01-21
Hi Jeff,
OIT indeed.. . .!
Thank for taking the time to reply to my questions. Very helpful!!
In response to your responses. . .
Jeff:
1) What you said about using a function generator for HRDY above -- do not do
that. The C6713 will generate HRDY,
that's its job, and your host (Dragon 12Plus board) needs to pay careful
attention to HRDY, that's its job. If HRDY
never goes high then something is wrong -- somehow you got the HPI internal
state-machine stuck. Probably only a
C6713 Reset fixes that.
Jones: So I am just simulating HRDY on the Dragon12 plus, not connected to DSK yet. The test program pools HRDY' (the fake one from the function generator).
I did this just to make sure my program was generating a waveform matching the ref. guide's (HAS Unused) Write. It matches. HCS' basically stays low after the first time it detects HRDY' low. I keep HSD2 tied high, and toggle HDS1 to generate the required internal HSTROBE' signal for the first and second writes.
Jeff:
2) Carefully study TI docs on HPI read/write sequence. Typically you have /HCS
enabled; in fact it's Ok to leave it
like that. Then check HRDY, if low wait, when high perform the transfer. Make
sure that HR/W is set before /HDS
(strobe).
Jones:
In my test program. . .
HCS' basically stays low after the first time it detects HRDY' low. I keep HSD2 tied high, and toggle HDS1 to generate the required internal HSTROBE' signal for the first and second writes. This sequence is is the same for HPIC, HPIA, and HPID writes (except for respective HCNTL bits, and the 16 HD pins.
I do need to verify that HRW' is set before the HDS1' strobe. Thanks for that.
Jeff:
3) Debug strategy: get read working first. Initially just read the HPIC
register, as it contains a known value after...
Jones:
I will definitely follow your suggested debug strategy. Makes sense. Again Thank You.
Jeff:
4) Your cable has to be very short and the 12Plus should have substantial drive
capability on its I/O lines, maybe 15
to 20 mA at 3.3V. You should carefully check /HDS on your MS0-2014 scope and
make sure it doesn't have falling edge
glitches that could be interpreted as a double-strobe. Also make sure overshoot
and undershoot (ringing) are within
TI's specs.
Jones:
The cable I am using is too long. It is ~10" . . . 10" noisy antennas: ha ha . .
I may be able to get them down to a little less than half that. It will be a challenge to
get the boards close enough (or on top of each other). So is it safe to say very short is < 3"?
I do own the HPI daughter card; however, it already has a MSP430 on it. It seems overkill for what I want to do. All the reference material for the card just mentions RTDX functionality for software apps in MATLAB, User Apps, etc. . . So I don't know, and I think, that it will not be of any use to me in regard to solving my cable length issue. Do you agree?
Final Thoughts:
Jeff, again, thank you for your reply. It is valuable advice.
Thanks for Your Time,
Mike Jones
_____________________________________
OIT indeed.. . .!
Thank for taking the time to reply to my questions. Very helpful!!
In response to your responses. . .
Jeff:
1) What you said about using a function generator for HRDY above -- do not do
that. The C6713 will generate HRDY,
that's its job, and your host (Dragon 12Plus board) needs to pay careful
attention to HRDY, that's its job. If HRDY
never goes high then something is wrong -- somehow you got the HPI internal
state-machine stuck. Probably only a
C6713 Reset fixes that.
Jones: So I am just simulating HRDY on the Dragon12 plus, not connected to DSK yet. The test program pools HRDY' (the fake one from the function generator).
I did this just to make sure my program was generating a waveform matching the ref. guide's (HAS Unused) Write. It matches. HCS' basically stays low after the first time it detects HRDY' low. I keep HSD2 tied high, and toggle HDS1 to generate the required internal HSTROBE' signal for the first and second writes.
Jeff:
2) Carefully study TI docs on HPI read/write sequence. Typically you have /HCS
enabled; in fact it's Ok to leave it
like that. Then check HRDY, if low wait, when high perform the transfer. Make
sure that HR/W is set before /HDS
(strobe).
Jones:
In my test program. . .
HCS' basically stays low after the first time it detects HRDY' low. I keep HSD2 tied high, and toggle HDS1 to generate the required internal HSTROBE' signal for the first and second writes. This sequence is is the same for HPIC, HPIA, and HPID writes (except for respective HCNTL bits, and the 16 HD pins.
I do need to verify that HRW' is set before the HDS1' strobe. Thanks for that.
Jeff:
3) Debug strategy: get read working first. Initially just read the HPIC
register, as it contains a known value after...
Jones:
I will definitely follow your suggested debug strategy. Makes sense. Again Thank You.
Jeff:
4) Your cable has to be very short and the 12Plus should have substantial drive
capability on its I/O lines, maybe 15
to 20 mA at 3.3V. You should carefully check /HDS on your MS0-2014 scope and
make sure it doesn't have falling edge
glitches that could be interpreted as a double-strobe. Also make sure overshoot
and undershoot (ringing) are within
TI's specs.
Jones:
The cable I am using is too long. It is ~10" . . . 10" noisy antennas: ha ha . .
I may be able to get them down to a little less than half that. It will be a challenge to
get the boards close enough (or on top of each other). So is it safe to say very short is < 3"?
I do own the HPI daughter card; however, it already has a MSP430 on it. It seems overkill for what I want to do. All the reference material for the card just mentions RTDX functionality for software apps in MATLAB, User Apps, etc. . . So I don't know, and I think, that it will not be of any use to me in regard to solving my cable length issue. Do you agree?
Final Thoughts:
Jeff, again, thank you for your reply. It is valuable advice.
Thanks for Your Time,
Mike Jones
_____________________________________
Reply by ●January 21, 20112011-01-21
Michael-
> Hi Jeff,
> OIT indeed.. . .!
> Thank for taking the time to reply to my questions. Very helpful!!
> In response to your responses. . .
>
> Jeff:
> 1) What you said about using a function generator for HRDY above -- do not do
> that. The C6713 will generate HRDY,
> that's its job, and your host (Dragon 12Plus board) needs to pay careful
> attention to HRDY, that's its job. If HRDY
> never goes high then something is wrong -- somehow you got the HPI internal
> state-machine stuck. Probably only a
> C6713 Reset fixes that.
>
> Jones: So I am just simulating HRDY on the Dragon12 plus, not connected
> to DSK yet. The test program pools HRDY' (the fake one from the function
> generator).
>
> I did this just to make sure my program was generating a waveform
> matching the ref. guide's (HAS Unused) Write. It matches. HCS'
> basically stays low after the first time it detects HRDY' low. I
> keep HSD2 tied high, and toggle HDS1 to generate the required
> internal HSTROBE' signal for the first and second writes.
Well as I said: don't think in those terms (simulation). It leads you down the
wrong path -- you have the full hardware right there in front of you, so implement
the correct interface, step-by-step and carefully check every step. By thinking
"simulation" you're starting to make assumptions. For example one bad assumption
you're making is that you can correctly detect HRDY before /HCS is low. Without /HCS
low the HPI interface is inactive; i.e. you can't trust what you read on HRDY.
> Jeff:
> 2) Carefully study TI docs on HPI read/write sequence. Typically
> you have /HCS enabled; in fact it's Ok to leave it
> like that. Then check HRDY, if low wait, when high perform the
> transfer. Make sure that HR/W is set before /HDS
> (strobe).
>
> Jones:
> In my test program. . .
> HCS' basically stays low after the first time it detects HRDY'
> low. I keep HSD2 tied high, and toggle HDS1 to generate the
> required internal HSTROBE' signal for the first and second
> writes. This sequence is is the same for HPIC, HPIA, and HPID
> writes (except for respective HCNTL bits, and the 16 HD pins.
>
> I do need to verify that HRW' is set before the HDS1' strobe.
> Thanks for that.
Other than the HCS/HRDY issue, that sounds fine. Remember, prior to *each* transfer
you have to be sure HRDY is high (active, not sure if I got the correct polarity).
Typically HRDY will be ready, but if you start writing DSP code that makes heavy use
of DMA channels then there may be times when the HPI's implicit DMA channel has to
wait. That's when not paying attention to HRDY would cause serious problems.
> Jeff:
> 3) Debug strategy: get read working first. Initially just read
> the HPIC register, as it contains a known value after...
>
> Jones:
> I will definitely follow your suggested debug strategy. Makes
> sense. Again Thank You.
>
> Jeff:
> 4) Your cable has to be very short and the 12Plus should have substantial drive
> capability on its I/O lines, maybe 15
> to 20 mA at 3.3V. You should carefully check /HDS on your MS0-2014 scope and
> make sure it doesn't have falling edge
> glitches that could be interpreted as a double-strobe. Also make sure overshoot
> and undershoot (ringing) are within
> TI's specs.
>
> Jones:
> The cable I am using is too long. It is ~10" . . . 10" noisy antennas: ha ha . .
> I may be able to get them down to a little less than half that. It will be
> a challenge to get the boards close enough (or on top of each other). So is
> it safe to say very short is < 3"?
Yes that's fine, just be sure to check the signals carefully on your Tek Mso 2014.
You guys got good equipment at OIT, so be sure to take advantage of that.
> I do own the HPI daughter card; however, it already has a MSP430 on it.
> It seems overkill for what I want to do. All the reference material for
> the card just mentions RTDX functionality for software apps in MATLAB,
> User Apps, etc. . . So I don't know, and I think, that it will not be
> of any use to me in regard to solving my cable length issue. Do you agree?
Daughtercard -- do you mean the one from Educational DSP LLC? As I understand it,
you are implementing an embedded system, and I believe eDSP's HPI daughtercard is
intended for PC interface, not an embedded system where a CPU or FPGA has direct
access to the HPI. Also you're supposed to be learning about TI's C6x series
devices, true? TI uses HPI on a lot of C5000 and C6000 devices and the concept of a
slave interface with direct access to onchip memory, accessible to an external host
CPU, is a basic one, well worth understanding.
-Jeff
_____________________________________
> Hi Jeff,
> OIT indeed.. . .!
> Thank for taking the time to reply to my questions. Very helpful!!
> In response to your responses. . .
>
> Jeff:
> 1) What you said about using a function generator for HRDY above -- do not do
> that. The C6713 will generate HRDY,
> that's its job, and your host (Dragon 12Plus board) needs to pay careful
> attention to HRDY, that's its job. If HRDY
> never goes high then something is wrong -- somehow you got the HPI internal
> state-machine stuck. Probably only a
> C6713 Reset fixes that.
>
> Jones: So I am just simulating HRDY on the Dragon12 plus, not connected
> to DSK yet. The test program pools HRDY' (the fake one from the function
> generator).
>
> I did this just to make sure my program was generating a waveform
> matching the ref. guide's (HAS Unused) Write. It matches. HCS'
> basically stays low after the first time it detects HRDY' low. I
> keep HSD2 tied high, and toggle HDS1 to generate the required
> internal HSTROBE' signal for the first and second writes.
Well as I said: don't think in those terms (simulation). It leads you down the
wrong path -- you have the full hardware right there in front of you, so implement
the correct interface, step-by-step and carefully check every step. By thinking
"simulation" you're starting to make assumptions. For example one bad assumption
you're making is that you can correctly detect HRDY before /HCS is low. Without /HCS
low the HPI interface is inactive; i.e. you can't trust what you read on HRDY.
> Jeff:
> 2) Carefully study TI docs on HPI read/write sequence. Typically
> you have /HCS enabled; in fact it's Ok to leave it
> like that. Then check HRDY, if low wait, when high perform the
> transfer. Make sure that HR/W is set before /HDS
> (strobe).
>
> Jones:
> In my test program. . .
> HCS' basically stays low after the first time it detects HRDY'
> low. I keep HSD2 tied high, and toggle HDS1 to generate the
> required internal HSTROBE' signal for the first and second
> writes. This sequence is is the same for HPIC, HPIA, and HPID
> writes (except for respective HCNTL bits, and the 16 HD pins.
>
> I do need to verify that HRW' is set before the HDS1' strobe.
> Thanks for that.
Other than the HCS/HRDY issue, that sounds fine. Remember, prior to *each* transfer
you have to be sure HRDY is high (active, not sure if I got the correct polarity).
Typically HRDY will be ready, but if you start writing DSP code that makes heavy use
of DMA channels then there may be times when the HPI's implicit DMA channel has to
wait. That's when not paying attention to HRDY would cause serious problems.
> Jeff:
> 3) Debug strategy: get read working first. Initially just read
> the HPIC register, as it contains a known value after...
>
> Jones:
> I will definitely follow your suggested debug strategy. Makes
> sense. Again Thank You.
>
> Jeff:
> 4) Your cable has to be very short and the 12Plus should have substantial drive
> capability on its I/O lines, maybe 15
> to 20 mA at 3.3V. You should carefully check /HDS on your MS0-2014 scope and
> make sure it doesn't have falling edge
> glitches that could be interpreted as a double-strobe. Also make sure overshoot
> and undershoot (ringing) are within
> TI's specs.
>
> Jones:
> The cable I am using is too long. It is ~10" . . . 10" noisy antennas: ha ha . .
> I may be able to get them down to a little less than half that. It will be
> a challenge to get the boards close enough (or on top of each other). So is
> it safe to say very short is < 3"?
Yes that's fine, just be sure to check the signals carefully on your Tek Mso 2014.
You guys got good equipment at OIT, so be sure to take advantage of that.
> I do own the HPI daughter card; however, it already has a MSP430 on it.
> It seems overkill for what I want to do. All the reference material for
> the card just mentions RTDX functionality for software apps in MATLAB,
> User Apps, etc. . . So I don't know, and I think, that it will not be
> of any use to me in regard to solving my cable length issue. Do you agree?
Daughtercard -- do you mean the one from Educational DSP LLC? As I understand it,
you are implementing an embedded system, and I believe eDSP's HPI daughtercard is
intended for PC interface, not an embedded system where a CPU or FPGA has direct
access to the HPI. Also you're supposed to be learning about TI's C6x series
devices, true? TI uses HPI on a lot of C5000 and C6000 devices and the concept of a
slave interface with direct access to onchip memory, accessible to an external host
CPU, is a basic one, well worth understanding.
-Jeff
_____________________________________
