Hi jjacp,
First off all - thank you for your appreciation.
Now, coming back to your issue I think it is related to the order of block execution: check this topic - https://community.nxp.com/thread/449904#comment-899761
I've opened your model and i see that "Hall Sensors Initial Position block" is executed after "Hall Event ISR"
Please change the priority of the "Chart" to 1 and check if it works.
Furthermore, if this does not solve your issue, is there any possibility for you to check with an oscilloscope is you have some sort of debouncing on hall input lines ?
Thank you!
Danie
Hi jjacp,
I've looked a little bit deeper in the model. For some unknown reason - MATLAB changed the execution order to the blocks (i do not understand why is that happening).
It generates the code for the ISR before eTIMER peripheric initialization code and cause the application to crash.
Please change the priority field of each blocks to look like this: eTimer configuration and then ISRs blocks
You can test this very easily using only the MPC5744P DevKit (no shield attached) plus a simple wire that could be connected to a pulse generator for HALL_xxx. (i kept mine near a switching power supply to act as an antenna)
In the end, with the modified properties + this hw setup I was able to execute the application correctly. Please check this short video.
Best regards,
Daniel
I fixed the priority values of the blocks you mentioned, and ran the code using only the main board (MOTORGD shield removed). It seems to work like in your video! I only see the count increase when I connect a stray wire to the J5 header.
However, once I put the shield back on, the problem of the perpetually increasing counter is still there.
I think I found a solution though. Since it seems the problem is due to line noise, I enabled the eTimer input filtering mechanism:
Using these settings make the HallCount variable stable, and the system behaves like it should. This work-around should be acceptable, right?
Also, I noticed in your lecture video that the input power port on your MOTORGD board is a two-wire interface, whereas on my board it is a barrel connector. I bought my board last month (Oct 2017). Could there be a hardware change that was made that affects or adds noise on the HALL input lines?
Thanks!!
Hi jjacp,
Glad you made it!
Using these settings make the HallCount variable stable, and the system behaves like it should. This work-around should be acceptable, right?
Yes, it is the correct way to do it in case you're dealing with noisy signals. You might need to tweak the parameters until you get a good balance between reading delay and noise rejection.
Also, I noticed in your lecture video that the input power port on your MOTORGD board is a two-wire interface, whereas on my board it is a barrel connector. I bought my board last month (Oct 2017). Could there be a hardware change that was made that affects or adds noise on the HALL input lines?
I used a rev. A of the Motor GD Development Kit. Between rev. B and rev. A there are a few modifications but nothing to interfere with HALL/ENC signals
Here is a diff between Rev A/B with electrical components changes.
Nonetheless, please do a simple test: unplug the hall signals from the sockets (maintain the +5 and GND connection over Motor GD JP1) and check with and oscilloscope if you have noise on the lines. If you do, then perhaps is due to your motor or 5v power supply.
Hope it helps!
Daniel
