Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Control transfer gets anulled (?) after some 120 seconds #6

Open
JohnCC330 opened this issue Jan 16, 2015 · 4 comments
Open

Control transfer gets anulled (?) after some 120 seconds #6

JohnCC330 opened this issue Jan 16, 2015 · 4 comments

Comments

@JohnCC330
Copy link

This is my first experience with USB programming, so it is maybe a little adventurous...

I took the control-transfer example C-code, and the unit-test PIC code. I adapted the PIC code for use with the 18F2550, and removed all code from the 'while'. In the data_cb routine I take the first byte of the buf and send it to 4 LEDs which are connected to the PIC.

In the host C code, I changed the code slightly to parse an argument which says which LED to switch on.

Everything works fine, I can select each LED correctly. But after about 120 seconds the LEDs switch off. Checking with Wireshark, I notice that this happens when the host interrogates the hub.

This is the part from the control program:

URB_CONTROL out    (sends the LED mask)
URB_CONTROL out    (sends an empty data packet ?)

then, when the LEDs switch off:

URB_INTERRUPT in
URB_INTERRUPT in
GET_STATUS Request  (to the HUB)
GET_STATUS Response   (to the HUB)
CLEAR_FEATURE Request   (to the HUB)
URB_CONTROL out
CLEAR_FEATURE Request
....

I can't see that the LED port is actually changed anywhere, so I suspect that the microprocessor is resetting. Could this be the result from this activity (which doesn't originate from the program)?

And, if so, how do I solve this problem?

@signal11
Copy link
Owner

I can't see that the LED port is actually changed anywhere, so I suspect that the microprocessor is resetting.

You should be able to trap that in the debugger.

Could this be the result from this activity (which doesn't originate from the program)?

Check your interrupt flags. There could be lots of things happening here.

And, if so, how do I solve this problem?

Debugging :-D

Also, don't waste your time with a 2550. It's an old, expensive, MCU. There are much better 8-bit MCUs from Microchip for a fraction of the price nowdays. Only ancient tutorials and textbooks recommend the 2550/4550.

Alan.

@JohnCC330
Copy link
Author

On Mon, 19 Jan 2015 06:45:39 -0800
Alan Ott [email protected] wrote:

I can't see that the LED port is actually changed anywhere, so I suspect that the microprocessor is resetting.

You should be able to trap that in the debugger.

Hi Alan,

Thanks for reply. To be honest, I gave up on the m-stack. I don't have
any debugger hardware, and I don't think I can simulate this in the
simulator.

Interrupts are not enabled at all. I call(ed) the processing function
of m-stack continuously, as I only wanted to set port A to the value of
the received byte. So, I just put that part in the data_cb function.

This works fine, except that the 'interrogation' after about 2 minutes
seems to reset the processor. Maybe the control_transfer left the stack
in some precarious state, or maybe there's some callback function
missing for one of other transactions.

Check your interrupt flags. There could be lots of things happening here.

No interrupt flags - no interrupts enabled.

Also, don't waste your time with a 2550. It's an old, expensive, MCU. There
are much better 8-bit MCUs from Microchip for a fraction of the price
nowdays. Only ancient tutorials and textbooks recommend the 2550/4550.

I know that. The only reason I used it is because I had a few left from
another project. If I don't use them, I'd be throwing the money away :)
And the experiments I'm doing are not for production either.

Cheers,
John

@signal11
Copy link
Owner

To be honest, I gave up on the m-stack. I don't have any debugger hardware,

PicKit 3 - $45 bucks iirc

Interrupts are not enabled at all.

That doesn't meant flags don't get set on reset.

The only reason I used it is because I had a few left from another project. If I don't use them, I'd be throwing the money away :)

Instead you're only throwing time away ;) I do the same kinds of stuff though...

Alan.

@JohnCC330
Copy link
Author

On Tue, 20 Jan 2015 18:09:29 -0800
Alan Ott [email protected] wrote:

To be honest, I gave up on the m-stack. I don't have any debugger hardware,

PicKit 3 - $45 bucks iirc

Hi Alan,

I've looked around and the cheapest version I can find (in Argentina)
is about the equivalent of US$85 (plus 21% VAT, so, about US$100 final).
Given the exchange rate, and the local wages, that is not an
insignificant amount. Maybe I can get the Olimex clone - I've seen
some good reviews.

Interrupts are not enabled at all.

That doesn't meant flags don't get set on reset.

I've solved the problem with the Microchip stack. If I find some time
I'll review the m-stack code and see if I can find a solution there.

I was very surprised though that the Microchip USB stack solution only
occupied only 4.5k words.

Anyway, again thanks!

Cheers,
John

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants