I've got a relatively complex program running on a 24HJ256GP610. I'm using
an FT245R for USB interface. This chip has a parallel interface to the
PIC. For debug, I made a small loop that reads data from the FT245R and
sends it back. Prior to the read, I sent a string to the chip. The string
write works properly, but the read always reads a null byte. However, if I
run the code in debug with the ICD-2, it works fine! I am not changing
optimization or anything. Just debug or program. The rest of the code
works fine. It's just this reading from the FT245R that does not work.
So... what is different between running something under debug?
On Jan 11, 2008 4:06 AM, Harold Hallikainen <spam_OUTharoldTakeThisOuThallikainen.org> wrote:
> I've got a relatively complex program running on a 24HJ256GP610. I'm using
> an FT245R for USB interface. This chip has a parallel interface to the
> PIC. For debug, I made a small loop that reads data from the FT245R and
> sends it back. Prior to the read, I sent a string to the chip. The string
> write works properly, but the read always reads a null byte. However, if I
> run the code in debug with the ICD-2, it works fine! I am not changing
> optimization or anything. Just debug or program. The rest of the code
> works fine. It's just this reading from the FT245R that does not work.
>
> So... what is different between running something under debug?
>
If you monitor some SFRs, then ICD2 will read it. This might make
some difference in some situations. I've no experiences with PIC24H
but I was having a problem with 12F629 Comparator module last time.
It was working under ICD2 but was not working in certain cases. It was
due to the fact I failed to read an SFR to clear the mismatch condition.
The other possibility is the configuration bits. If you use ICD2 debugging,
typically MPLAB will assume certain default configuration if you have not
defined all of the configuration bits explicitly.
> Harold,
>
> I am familiar with this problem.
>
> 1. you do not have enough decoupling caps on the board
> when you plug in caps on ICD2 works
> 2. you do not have reset pull-up resistor
>
> if you forgot about reset pull-up you can use internal reset
>
>
> Andre Abelian
Thanks! I would think that these would generally mess up everything. Here,
my entire project is running, but if I set a simple USB loopback (read
FT245R and, if there's a character, write it back), all characters are
looped back as nulls. Prior to entering the loop, I sent "Hello World" out
the FT245R, and it appeared properly on Bray's Terminal watching the
virtual com port the FT245 was going to. So, it looks like I'm reading
nulls since the Hello World worked. The FT245R is a parallel bus
interface. I've got it on the 8 lsb of port b. It works in debug, but not
without the debugger.
As for the rest of the application, I'm reading a camera chip and driving
a display module. The display is also on portb. The camera and display are
working fine.
The reading of the FT245R is very simple. I tristate portb, drive rdn low,
wait about 100ns, copy the 8 lsb of portb to the result (this is written
in C), then drive rdn high. Simple enough... Works in debug....
At 03:06 PM 1/10/2008, you wrote:
>I've got a relatively complex program running on a 24HJ256GP610. I'm using
>an FT245R for USB interface. This chip has a parallel interface to the
>PIC. For debug, I made a small loop that reads data from the FT245R and
>sends it back. Prior to the read, I sent a string to the chip. The string
>write works properly, but the read always reads a null byte. However, if I
>run the code in debug with the ICD-2, it works fine! I am not changing
>optimization or anything. Just debug or program. The rest of the code
>works fine. It's just this reading from the FT245R that does not work.
>
>So... what is different between running something under debug?
>
>THANKS!
>
>Harold
Check your initialization. Debug does some things with TRIS registers,
which don't happen without debug.
Could you explain your hw design? How it powered for example?
Can you see the data bits from the FT chip with an oscilloscope?
I know it sounds stupid, but is the internal pull-up enabled for portb?
As you use C I am not sure if there is anything about watching files or
doing something with tris by the debugger as you do it upfront receiving
chars.
> At 03:06 PM 1/10/2008, you wrote:
> >I've got a relatively complex program running on a 24HJ256GP610. I'm
> using
> >an FT245R for USB interface. This chip has a parallel interface to the
> >PIC. For debug, I made a small loop that reads data from the FT245R and
> >sends it back. Prior to the read, I sent a string to the chip. The string
> >write works properly, but the read always reads a null byte. However, if
> I
> >run the code in debug with the ICD-2, it works fine! I am not changing
> >optimization or anything. Just debug or program. The rest of the code
> >works fine. It's just this reading from the FT245R that does not work.
> >
> >So... what is different between running something under debug?
> >
> >THANKS!
> >
> >Harold
>
> Check your initialization. Debug does some things with TRIS registers,
> which don't happen without debug.
>
> >Best regards,
>
> Spehro Pefhany --"it's the network..." "The Journey is the
> reward"
> .....speffKILLspam.....interlog.com Info for manufacturers:
> http://www.trexon.com
> Embedded software/hardware/analog Info for designers:
> http://www.speff.com
>
>
>
> Hi Harold,
>
> Could you explain your hw design? How it powered for example?
> Can you see the data bits from the FT chip with an oscilloscope?
> I know it sounds stupid, but is the internal pull-up enabled for portb?
>
> As you use C I am not sure if there is anything about watching files or
> doing something with tris by the debugger as you do it upfront receiving
> chars.
>
> Tamas
>
I'd like to hang a logic analyzer on there and see what's going on, but
the pins are so small that it's a real pain! The FT chip is a QFN, so
there's nothing to clip on to there. The PIC has leads, but very small and
very close together. I dread asking the tech to solder a bunch of wires on
there so I can see what's going on. Might be necessary, though!
I just looked @ FT245 usb board now I am wondering if there is
any reason to use that board if there is 18F4550 usb built in.
I have been using this chip over 6 months now. All I can tell is
it does fantastic job no external component needed.
To me any external components will add more work for you.
>
> Harold,
>
> I just looked @ FT245 usb board now I am wondering if there is
> any reason to use that board if there is 18F4550 usb built in.
> I have been using this chip over 6 months now. All I can tell is
> it does fantastic job no external component needed.
> To me any external components will add more work for you.
>
> Can I see your schematic ?
>
> thanks
>
> Andre
The 18F is not fast enough for this application. I'm using a 24HJ256GP610
running at 40MIPS. I'll consider the 18F4550 for future stuff, but our
speed requirements always seem to be increasing.
I use 18F4550 20 mhz with PLL enabled that internal clock is 48 mhz.
Faster crystal will make more noise. I didn't use 24HJ256GP610 so
I do not know any thing about it for now.
48MHz 18F has 12MIPS, Harold needs 40 or more. Maybe one day he will try the
new 32bit pic and tell us how is that good? :-)
BTW: SX chips tend to have more than that, however, those do not contain any
periferie so maybe the overall performance would have been even less.
Harold, you might can use a smaller pic as a communication and acquisition
interface and sx as a calculation one - just wondering...
> Harold,
>
> I use 18F4550 20 mhz with PLL enabled that internal clock is 48 mhz.
> Faster crystal will make more noise. I didn't use 24HJ256GP610 so
> I do not know any thing about it for now.
>
> Andre
>
>
>
>
> Hi Andre,
>
> 48MHz 18F has 12MIPS, Harold needs 40 or more. Maybe one day he will try
> the
> new 32bit pic and tell us how is that good? :-)
> BTW: SX chips tend to have more than that, however, those do not contain
> any
> periferie so maybe the overall performance would have been even less.
> Harold, you might can use a smaller pic as a communication and acquisition
> interface and sx as a calculation one - just wondering...
>
> Tamas
>
Thanks for the ideas! I'm using the 24HJ256GP610. I have something like a
10 bit parallel interface to a cmos image sensor chip (plus a bunch of
control lines), an 8 bit interface to a graphic display module and the
FT245R USB interface. There's also an SPI interface to an 802.11 radio
module and SD card. So, I've used almost all the pins. I like having all
the processing in one chip. I MIGHT try moving to a PIC32 at some point,
but this seems to be fast enough. 10MIPS would definitely not be fast
enough. The image sensor would forget the bottom of the image by the time
I got to shifting it out.
hallikainen.org> wrote:
